google oauth2 - Should I send the Secret with the Refresh Token in OAuth 2.0 -
i'm working implement oauth 2.0 server, , while reading rfc6749 specification realized section 6 on page 47 regarding "refreshing access token". explains need use refresh token have new token.
but example, in addition refresh token, google require user id , secret so.
this confuses me, because on 1 hand have google processing high volume of requests every day, , have specification written smaller scope in mind.
is send secret every hour refresh token?
personally believe no: because user id , secret should used go on whole oauth 2.0 process.
basically
- you use token on each request prove are.
- refresh token used once hour (and potentially changed @ each refresh)
- secret , user id go internet possible. when option 1 , 2 compromised.
i believe sending secret refresh token less secure. maybe i'm missing something.
if have point of view, please share :)
i might missing something, what google requires , what's specified oauth2 when refreshing token confidential client application client must authenticate itself.
the common type of credentials being used confidential clients client identifier alongside client secret. information issued client application , unrelated end-user.
by requiring client authentication authorization server can sure request comes specific client , adjust response accordingly. example, authorization server can decide permissions - scopes - can requested confidential clients.
the argument around reducing number of times client secret needs sent on wire non-issue. oauth2 mandates communication happens on tls , if have issues sending secret have issues sending bearer access tokens.
in conclusion, although doing things according spec without questioning overall context might lead vulnerabilities:
... libraries treated tokens signed
none
algorithm valid token verified signature. result? can create own "signed" tokens whatever payload want, allowing arbitrary account access on systems.
(source: critical vulnerabilities in json web token libraries)
some libraries treated none
algorithm according spec, ignored usage context; if developer passed key verify signature did not want treat unsigned tokens valid.
however, passing secret on refresh token request not 1 of these situations don't worry it.
Comments
Post a Comment