3

I'm trying to implement the OAuth2 resource owner flow. My authorization server successfully generates JSON web tokens, so my next step is to implement refresh tokens for my web application.

Everything that I have read explains that when requesting an access token from your authorization server you include the resource server URL as the client_id. This is then put in an aud claim within your JWT. Is this correct?

If so, my issue arises when I try to implement refresh tokens. Refresh tokens are issued on a per client basis, so that client_id field now needs to identify the client, and not the resource server URL. With this being the case, my authorization server now doesn't know who to issue the token for, so it doesn't know what to add in the aud claim within the JWT.

I'm looking for some advice on the best approach to solve this issue in relation to the OAuth2 spec, there doesn't seem to be a concrete answer out there for this problem when mixing OAuth2 and JWT.

Does anyone have any ideas?

My current flow looks like this:

  1. Client sends request to authorization server with username in the username field, password in the password field and the resource server it wants access to in the client_id field.

  2. Authorization server validates the username and password, and checks if it can generate a JWT for the requested resource server.

  3. It returns a token if both of those checks pass, the token contains an aud claim which matches the client_id that came in the request.

1 Answer 1

2

Everything that I have read explains that when requesting an access token from your authorization server you include the resource server URL as the client_id. This is then put in an aud claim within your JWT. Is this correct?

No, that's not. The 'client' is an entity that perfoms the request, and it should be identifiable and audited independently from the resource server ( and there can be multiple clients for the same resource).
OAuth 2.0 specification provides the following definition for client_id

a unique string representing the registration information provided by the client. The client identifier is unique to the authorization server.

For resource owner flow client credentials can be skipped only if the client is not confidential (https://www.rfc-editor.org/rfc/rfc6749#section-2.1), in other case pre-registration would be preferred (client should be issued unique client_id and client_secret).

By the way, according to the specification you don't need any client credentials to refresh access token. The only required parameters are grant type (should be set to "refresh_token") and refresh token itself.

Regarding JWT token and "aud" claim

The "aud" (audience) claim identifies the recipients that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in the audience claim.

In other words it's a JWT equivalent for client_id. And the same rules as for client_id are applicable. I recommend to go into OpenID Connect specification that is build on top of OAuth and has a lot of prescriptions how to work with JWT tokens and OAuth 2.0 protocol as well as detaild explanation of JWT claims usage.

I can suggest the following options to your problem

  1. Do not use "aud" claim in resource owner flow, as it is optional for OAuth (but required for OpenID Connect)
  2. Issue a real client_id and fill "aud" by this value (actually depends on client type - is it confidential or not)
1
  • Thanks for taking the time to respond! Just what I was looking for. It makes sense now I understand the aud claim is an identifier for the client receiving the token, and not the resource server its going to be used with. I'll check the article out too.
    – Developer
    Dec 7, 2015 at 11:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .