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

  1. you use token on each request prove are.
  2. refresh token used once hour (and potentially changed @ each refresh)
  3. 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

Popular posts from this blog

php - How to add and update images or image url in Volusion using Volusion API -

javascript - jQuery UI Splitter/Resizable for unlimited amount of columns -

javascript - IE9 error '$'is not defined -