This is about Oauth services provided by Auth0
Structure
Auth0 is a full service provider for Oauth2 integration. You can define users, roles, applications, roles, permissions etc.
- users – regular users, login and password
- applications – applications; they have client_id, client_secret and can be allowed to use various grant types as per openid and oauth2 specification. Grant types include authorization_code, password, client_credentials etc
- api – the ultimate endpoint. They define a list of permissions and the audience. The token must be cut for an audience, not more. Audience is very well checked when your application verifies the token, so it is important you properly set it
- Domain – you get a domain when you create the account. All the urls for getting the token, processing the authentication redirect etc are based on that domain.
- roles – merely permission collections, for easier handling
How do you do it
- setup application – get client id, client secret, choose the grant types etc.
- setup API, choose audience, create permissions
- create whatever users
In the application, under “advanced” (right at the end) and endpoints you got all the endpoints you need to run your operation, see below:
Definitely all of them are interesting, see couple of explanations
- authorization url: you redirect to that url (with a bunch of parameters) and auth0 prompts you for login and password. It would then redirect back to your application to the redirect_uri you provided
- oauth token url: once you got the temporary auth code, or you use client_credentials or password, you proceed to this url and you get the token. Post is only accepted and note the url is of course over SSL
- json web key set – your client needs this url because this is the place where it will download the public keys from. The keys will be used to validate the token. Very important
Sample Requests
Password grant type
This is good merely for example of how to put together the request. Otherwise, nobody encourages the solution designers to use this grant type because it means your application will have exposure to the credentials.
Here is the request
Don’t worry, the credentials are no longer useable :). So you see grant_type, password, client id and secret which ties the user to the api and to the application. Scope is a list of permissions associated with the specified api, and audience is the audience defined for that api. Note the url where all this is posted.
Client Credentials
Client credentials defines the fact that the application can obtain a token to be used against the api for business to business calls. Note that since the application has only one client id and client secret, clearly there is only one set of credentials.
How you enable this. So you go under the api, enable the application, then when enabled, you must click on the drop down on the right of the enable button to select also whatever scopes (permissions) the application can claim when a token is being cut. Very important.
Here is how the screen looks like:
And now we post the request, and here it is
Note how only client id and secret are present as credentials. This is typical for business to business. Scope has the permissions that are subset of permissions the api requires and the application can access, and audience is the api’s audience.