Possibly this is a silly question, but why not #2 and have the bearer token method (over SSL of course) include the token secret? The provider would always issue a token and a token secret. If the client is not interested in signing methods, it can discard the token and keep the token secret. This secret is never sent in the clear using a signing method. I believe that this is the approach taken in OAuth 1.0a and it seems like it should address this concern.
Ethan On Thu, Mar 11, 2010 at 1:58 AM, David Recordon <record...@gmail.com> wrote: > Has anyone else put some thought into what secrets are used within the > signature algorithm for OAuth 2.0? > > OAuth 1.0 combines the client secret and the token secret with an > ampersand in the middle. WRAP doesn't support signatures and relies > on the fact that access tokens should remain secret via SSL or are > extremely short lived and thus lower risk. > > Here are the options as far as I'm aware (without making changes to > WRAP's assumptions): > > 1) Sign using the client secret. Doesn't work because the access > token would be sent over the wire in plaintext and some servers will > make them long lived in 2.0. > > 2) Issue an access token secret if an optional parameter is specified > by the client during the authorization profile request(s). Doesn't > work for the same reason as #1 assuming that the same access token can > be used via SSL. > > 3) Instead of adding an optional parameter to each authorization > profile, have the client immediately refresh the access token and > support an optional parameter to request an access token secret. This > lessons the impact of supporting signatures on most implementors when > reading the spec and given that most signature use cases have longer > lived tokens, the overhead of the extra HTTP request should be > infrequent compared to the number of protected resource requests > you'll make with it. Doesn't work for the same reason as #1 assuming > that the same access token can be used via SSL. > > While I'm not a crypto expert, it seems impossible to treat the same > access token as potentially public when using signatures but secret > when using SSL. I believe that authorization servers will need to > keep track of the access tokens that the client has requested a secret > for and from that point on only allow the use of that particular > access token 1) via signatures or 2) via SSL when the access token > secret is passed in as well. > > Thoughts? > > Thanks, > --David > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
