Support client_secret on authorization_code grants #405
Labels
enhancement
New feature or request
Comments
evert
added a commit
that referenced
this issue
Sep 12, 2022
This became a bit bigger than expected, but: * Refactors the OAuth2 service to have more consistent function signatures. * Adds token statistics to the oauth2 homepage. * Stores the 'grant_type' and whether a 'secret' was used in the tokens table. * We're now storing 'scope' for every token. This OAuth2 feature wasn't really used by this server, but this sets up the first steps for this. * Fixes a bug related to generating principal uris in the introspection endpoints. * Has more explicit support for the 2 a12nserver-specific oauth2 flows: "developer tokens" and "one-time-tokens". Other side-effects of this PR: * A few step furthers in #405 * Some progress towards OpenID Connect support (scopes are important for this).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Pointed out in this ticket: badgateway/oauth2-client#70
authorization_code should support sending
client_secret. After we support this we should also ensure that ifclient_secretis passed to get the token, it should also be passed every time the token is refreshed. This means we need to start tracking if aclient_secretwas used to obtain the original token.This feature can pretty much be done in multiple steps:
client_secretwithauthorization_code.oauth2_tokentable which grant_type was used to issue the token.oauth2_tokenif aclient_secretwas used to issue the token.client_secretwas used to issue a token, it must be specified when refreshing the same token.The text was updated successfully, but these errors were encountered: