OAuthAuthorizationServer (OAuth 2) is confusing [2]

[Guilherme Reis]

Hello,

I'm using the beta version and I couldn't realize where (which point)
to store the access token.
The method PrepareAccessTokenResponse returns an
AccessTokenSuccessResponse, but it is an internal class, so I can't
get the parameters to store in database.

Would really appreciate some help, thanks.

[Andrew Arnott]

This is part of the "pit of success" philosophy: make doing it the right way as easy as falling into a pit (and make doing it wrong difficult).

The reason it's difficult to obtain the access token is because you're not supposed to store it at the authorization server. It's a self-describing, signed and encrypted token, and as such there is no value in storing it at the authorization server.  

What does get stored at the authorization server is the authorization itself (the client-user-scope tuple) such that your implementation of IAuthorizationServer.IsAuthorizationValid can return the appropriate boolean value based on what you stored previously.

Does that make sense?  Have I overlooked some scenario that requires that you store the access token?

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
To post to this group, send email to dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

--
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

[Jay Frysinger]

Is there a valid use case where a second request could be made with the same security context (user, requesting application etc..) and efficiencies can be gained from returning a cached token rather than creating a new one? I have seen that use case in a different paradigm.

JF

[Andrew Arnott]

I suspect in that scenario you're taking another few hits to your database server in order to spare your web server a little crypto.  Leaving the work on the web server would scale better than leveraging your db server I believe.  It would also help keep your database from bloating from all the access tokens it would have to generate.  A single user-client may obtain several access tokens (with different scopes and lifetimes) in order to improve security, so storing each one in the database can have quite a tax on the server as opposed to just signing a new token each time.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

[Jay Frysinger]

I think that approach would assume that the authorization server was mostly engaged in signing, and most or  all of the auth data required for the token is present in the inbound request. If that is true then I totally agree. The scenario I was coming from required the auth server to obtain some of the authorization information to be signed and included in the token, and hitting the cache outperformed retrieving that data. I’m likely coming from a different context, so excuse me if the observations aren’t relevant.