Skip to main content

Auth0: Authorization Flows

 Today I write this entry after a few late nights of personal research.  I am building an app and an important part of it will be to integrate it to other services using Zapier.  To do that, I need to make a REST-ful API layer with no login form, but instead to have an authorize routine which can take the user's credentials and to pass back an Access Token.

Up until now, other services I have helped establish have either used the Universal Login method, or simply with my own custom Javascript wrapper using the SDK.  Neither of these solutions is going to fit my need.  I did understand that from all of the available methods it had to offer, OAuth was going to fit it in some way, but I did not quite understand how I would evade having to use a login UI element.

I've now had more of a solid read over the Auth0 Authentication API documentation, and on the subject of Get Token, there are number of different types of login flows, the main key/value that determines one flow to the other is what is described in the "grant_type".  What caught my eye was the Resource Owner Password flow.  Using this I can pass-through the credentials from my API layer, and return back the response directly from Auth0 which contains the access token specifically for that user.

So, here is the start of my class:

When a user has their access token in the "Authorization" of their request header, I can then use getUser to get the details of that profile.  I have more testing to continue with, but I hope this takes out a load of headaches for you that I ran through!

One more thing...

You are more than likely going to first need to update your your Auth0 application to accept this particular grant type. Use your Auth0 domain and client ID in to this URL and use the following body:

{
  "grant_types": [
        "password",
        "http://auth0.com/oauth/grant-type/password-realm"
    ]
}

Of course, you'll need to first get your access token to make this kind of an update.


Comments

Popular posts from this blog

Running NodeJS Serverless Locally

 So it's been a long time, but I thought this was a neat little trick so I thought I'd share it with the world - as little followers as I have.  In my spare time I've been writing up a new hobby project in Serverless , and while I do maintain a staging and production environment in AWS, it means I need to do a deployment every time I want to test all of the API's I've drafted for it. Not wanting to disturb the yaml configuration for running it locally, I've come up with a simple outline of a server which continues to use the same configuration.  Take the express driven server I first define here: And then put a index.js  in your routes folder to contain this code: Voila! This will take the request from your localhost and interpret the path against your serverless.yml and run the configured function.  Hope this helps someone!

question2answer Wordpress Integration

 Today I want to journal my implementation of a WordPress site with the package of "question2answer".  It comes as self-promoted as being able to integrate with WordPress "out of the box".  I'm going to vent a small amount of frustration here, because the only integration going on is the simplicity of configuration with using the same database, along with the user authentication of WordPress.  Otherwise they run as two separate sites/themes. This will not do. So let's get to some context.  I have a new hobby project in mind which requires a open source stack-overflow clone.  Enter question2answer .  Now I don't want to come across as completely ungrateful, this package - while old, ticks all the boxes and looks like it was well maintained, but I need every  page to look the same to have a seamless integration.  So, let's go through this step by step. Forum Index Update This step probably  doesn't need to be done, but I just wanted to mak...

Getting all deltas from Auth0

Before I get in to the solution of this article, let me tell you how it started and fill you in on the problem that arose.  I wrote a procedure to get daily deltas of users - those of which who had created/updated their account on the given day (and including the day before for good measure on the GMT timestamp).  The simple search criteria was just the following: updated_at:[yyyy-mm-dd TO yyyy-mm-dd] Simple, right?  the []'s being the dates are inclusive, while using {} would mean exclusively.  Auth0 lets you mix these on either side depending on your use.  While this is all well and good, Auth0 will limit the number of results (even with paging) to 1000 only. So, your first option is that you could have your procedure create a user export job, and then parsing through the results and eliminating those which do not meet your updated_at search criteria.  I can tell you first hand that eventually the amount of users will just get to be too much and cumb...