-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introspection Response: access_token
and refresh_token
are not valid token_type
#1762
Comments
Triaged as a bug, we should find a better key name for |
I think |
Because you might want to prevent people from using a refresh token as the access token, given that they usually don't expire. |
I think
|
I think so, a good name! |
I just realized that the request parameters have a token_type_hint parameter which can be access_token or refresh_token (see also RFC7009) but then return token_type in a completely different context (related to the HTTP auth mechanism). Classic OAuth2 ... |
fix: returning valid token_type in introspection response ory/hydra#1762
See ory/hydra#1762 BREAKING CHANGE: Type `fosite.TokenType` has been renamed to `fosite.TokenUse`.
BREAKING CHANGE: Previously, the OAuth2 Token Introspection endpoint would return `access_token` or `refresh_token` for the key `token_type`. This however is not according to spec, which specifies `bearer` as the only valid (unless an extension is used) `token_type` parameter. Please be aware that `token_type_hint` in the **request parameters** is still correct. For more information consult [RFC7662](https://tools.ietf.org/html/rfc7662). If you wish to know if a token can be used as an access or refresh token, check the new `token_use` parameter! Closes #1762
Closes #1762 BREAKING CHANGE: This changes the OAuth2 Token Introspection response to ensure compliance with the OAuth2 Token Introspection specification. Previously, `token_type` would return `access_token` or `refresh_token`. The specification however mandates that `token_type` is always `Bearer`. This patch resolves that issue. The previous behaviour of `token_type` has now been moved to `token_use` which can be `access_token` or `refresh_token`.
Closes #1762 BREAKING CHANGE: This changes the OAuth2 Token Introspection response to ensure compliance with the OAuth2 Token Introspection specification. Previously, `token_type` would return `access_token` or `refresh_token`. The specification however mandates that `token_type` is always `Bearer`. This patch resolves that issue. The previous behaviour of `token_type` has now been moved to `token_use` which can be `access_token` or `refresh_token`.
Closes #1762 BREAKING CHANGE: This changes the OAuth2 Token Introspection response to ensure compliance with the OAuth2 Token Introspection specification. Previously, `token_type` would return `access_token` or `refresh_token`. The specification however mandates that `token_type` is always `Bearer`. This patch resolves that issue. The previous behaviour of `token_type` has now been moved to `token_use` which can be `access_token` or `refresh_token`.
Closes #1762 BREAKING CHANGE: This changes the OAuth2 Token Introspection response to ensure compliance with the OAuth2 Token Introspection specification. Previously, `token_type` would return `access_token` or `refresh_token`. The specification however mandates that `token_type` is always `Bearer`. This patch resolves that issue. The previous behaviour of `token_type` has now been moved to `token_use` which can be `access_token` or `refresh_token`.
Would token_type be Bearer or bearer? |
As for Introspection Spec and Access Token Spec,
bearer
andmac
are the only valid Access Tokens. Some framework (like Vertx OAuth2) may consider all othertoken_type
as invalidhttps://github.com/vert-x3/vertx-auth/issues/376 is the related issue
The text was updated successfully, but these errors were encountered: