Auth0 Home Blog Docs

Now that delegation is being deprecated, which Authorization Flow should we use?

api
delegation

#1

Currently we use Delegation to authorize our web client to call our API on behalf of a user.

Our basic flow is:

1- Client presents user with custom login page (we don’t use the Lock Widget, because of our business requirements).

2- Client POST request to /oauth/ro

{
  "client_id”:”ID”,
  ”client_secret”:”SECRET”,
  ”grant_type":"password",
  "connection":"Username-Password-Authentication",
  "username”:”USERNAME”,
  ”password”:”PASSWORD”,
  ”scope":"openid app_metadata email"
}

3- Client extracts id_token from response

4- Client POST request to /delegation

{
  "client_id”:”ID”,
  "target”:”API_I",
  "id_token”:”TOKEN”,
  ”grant_type":"urn:ietf:params:oauth:grant-type:jwt-bearer",
  "connection":"Username-Password-Authentication",
  "scope":"openid app_metadata email",
  "api_type":"app"
}

5- Client extracts bear token and makes API request

6- API validates JWT signature

7- API extracts app_metadata which contains claim information

Now that delegation is being deprecated, which Authorization Flow should we use. None of the new flows seem to support our use case/business requirements.

Also, when will the current delegation flows be deprecated and shut off?


#2

Your basic client flow is the de-facto use case for APIs
authentication
.

Basically you need to create a new API in the Dashboard => APIs
section and use the base URL of your API server in the Identifier
field. This will be reffered as Audience in your
access_tokens. Please use RS256 as signing algorithm (default one).

The next thing you need to request an access_token which is signed for that
specific audience. Depending on the client architecture you have
(web application, SPA, mobile app, etc) you need to use the
appropriate grant type in order to retrieve your access_token.

Since you are using the “Resource Owner Password
Grant” you can find more details about APIs invocation using this grant type here.

An example request for such a token would be the following:

curl --request POST \
--url 'https://{YOUR_AUTH0_DOMAIN}/oauth/token' \
--header 'content-type: application/json' \
--data '{"grant_type":"password","username": "{USERNAME}","password": "{PASSWORD}","audience": "{YOUR_API_AUDIENCE}", "scope": "openid create:timesheets write:calendar", "client_id": "{YOUR_CLIENT_ID}", "client_secret": "{YOUR_CLIENT_SECRET}"}'

By specifying the scope openid you will get an id_token as
well. The other scopes should be the scopes to access the
different endpoints of your API. You can always modify this scopes
via a rule and set them according to your user_metaedata like
this:

var roles = user.app_metadata.roles;
if (roles.indexOf("admin") >= 0) {
  context.accessToken.scope = "create:users delete:users read:users";
}

This access_token is the one which will be sent to your API
server for authentication and contains the allowed scopes. The
token validation must be done by retrieving the pubic key from
Auth0 using the public key from your API in the following
endpoint: https://YOUR_DOMAIN/.well-known/jwks.json. You can
find some examples in the Quick Start tab from your API
configuration settings in Auth0’s dashboard.

Once the issuer and signature have been validated you must validate
the scopes from the token against the invoked endpoint. If the
token does not contain the scope required to execute the current
endpoint an Unauthorized HTTP code (401) should be returned.

Also, when will the current delegation
flows be deprecated and shut off?

We are working on some new documentation that should explain the new flows more clearly. We will not stop the old delegation flow from working without plenty of notice, and the official deprecation won’t even start until we have provided more comprehensive documentation.


#3

You said:
“We are working on some new documentation that should explain the new flows more clearly.”

Well, where is it? I created a new account for a newer version of my app (which uses SDK7 delegation) and the delegation grant types are not available to me. So where’s the documentation? Where’s the code examples for how to use Auth0 and Firebase together using SDK8? Auth0 is turning out to be such a disappointment, always changing things and the documentation is way behind.


#4

You said:
“We are working on some new documentation that should explain the new flows more clearly.”

Well, where is it? I created a new account for a newer version of my app (which uses SDK7 delegation) and the delegation grant types are not available to me. So where’s the documentation? Where’s the code examples for how to use Auth0 and Firebase together using SDK8? Auth0 is turning out to be such a disappointment, always changing things and the documentation is way behind.


#5

Hi, are there any updates on the documentation? As a new user, have not seen any viable alternative for delegated token access to AWS API. The old guide (https://auth0.com/docs/integrations/aws/tokens) is outdated as jwt-bearer grant types are no longer supported. Appreciate any help.


#6

Yep, timely documentation for laymen like me would be most helpful. Or at least please respond and let me know where we are at in this process.


#7

I agree. I’ve spent the last three days trying to get Auth0 and Firebase working together and every step has been a massive struggle. There’s no documentation and with all the changes they put into every release the community and Stack Overflow help is now useless.
Firebase was a quick way to get my users up-and-going but I didn’t want to have to use it long-term, which is why I wanted to use Auth0 and not tie myself to Firebase Authentication, but it’s reached the point where I’ll likely never take another look at Auth0 again. Firebase Auth just works.


#8