Refresh token used as bearer token for Grant Management APIs

[Dima Postnikov]

From @Yaron Zehavi  https://bitbucket.org/openid/fapi/issues/407/grant-management-lifecycle#comment-60599018

Grant Management API -> API authorization - I suggest to consider securing the Grant Management API with the refresh token used as bearer token. This achieves several benefits:

• Removes burden from client to request a separate access token
• Simplifies AS implementation as it removes the need to look up the grant, instead relying on extracting grant id from the refresh token
• Provides stronger API security in case an attacker has succeeded to impersonate the client. Attacker would not be able to manipulate or query grants without also obtaining the individual refresh tokens

‌

[Ralph Bragg]

For FAPI this endpoint should support sender constrained tokens and this token should be sender constrained not a bearer token.

[Torsten Lodderstedt]

I would not use the refresh token for several reasons:

• refresh tokens are supposed to be consumed by the AS (more specifically its token endpoint only). Using the refresh token with an API means:

  • the AS needs to query the data associated with the refresh token using proprietary means and
  • the grant management API cannot be implemented using standard libraries.
  • The AS would even need to use another authorization header to pass the token as RFC 6750 explicitly states that the Bearer authorization header contains an access token.

• the client shall be able to access a grant even if the AS did not issue a refresh token for that grant

• the client shall be able to access all its grants, not just an individual grant

‌

[Ralph Bragg]

+ 1

[Dima Postnikov]

I can understand the intent to simplify, but recognise that this might not fit all use cases and existing frameworks. +1 to Torsten’s response.

[Yaron Zehavi]

Seeing the points raised here, I can’t help but agree

[Dima Postnikov]

Resolved