Re: [dotnetopenauth] OAuth2 - access_token as opaque token directly verifiable with AuthorizationServer

[Andrew Arnott]

Hi Robert,

I think your scenarios are quite valid.  I believe you can accomplish them regardless of the access token format, however.  I'll suggest how, and then I'd like to know whether you agree.

Although it's outside the scope of the spec, OAuth 2 resource server can forward each access token they receive to the authorization server to confirm that they are still valid.  This sounds like it's exactly what you're trying to do already, so I suppose you already have a plan to support such a service at the authorization server (just a simple URI endpoint that takes a POST whose payload is the access token, and responds with a valid/invalid response is probably sufficient).

The remaining bit is how your authorization server determines whether its valid or not.  There are at least a couple options here.  One is that your authorization server actually records every access token it generates in a database, removing them as they expire or upon revocation.  Then it's a simple lookup test to respond to the resource server.  It seems that should work with DNOA as it is today.  But it also means you have to store every single access token.  A perhaps superior implementation would be for the authorization server to also be able to decrypt the access token so that it can see the client_id/user/scope/date tuple and thereby determine whether the underlying authorization has been revoked.  This is precisely how the authorization server already determines the revocation/expiry status of refresh tokens, and allows for the auth server to not store any tokens at all.  

To summarize: If you're fine to store all access tokens at the auth server, I think you've got everything you need already.  If you'd rather not store them but still want revocations to be effective immediately (instead of when the access token expires) then we need DNOA auth servers to be able to decrypt access tokens.  

If we didn't rely on cryptography for access tokens to be self-describing, you'd absolutely have to store all access tokens.  Is there any scenario I've missed?

--
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

On Sun, Jun 17, 2012 at 2:45 AM, Robert Mircea <robert...@gmail.com> wrote:

Is there any chance to support an alternative generation method for access_tokens so that they do not use public key encryption/signature and instead they are verifiable by direct access to Authorization Server from Resource Server? I understand the benefits and the reason that drove you to issue access tokens which are not opaque, but in our case we would like to control revokation of access tokens with greater precision. I would like also to implement the following scenarios in Authorization Server which really depend on valability of access tokens:

• The provider will have a revokation URL where the client can make a HTTP GET to revoke access or refresh tokens
  
• The access token should become invalid if the user will change his password or if he logs out from the online service, for example.
• If the user's account is suspended or deleted all tokens should become invalid
• If client application is deleted/uninstalled, all tokens should be revoked by the app by calling the provider at a certain URL in order to invalidate them

It would be nice if the framework would allow by configuration settings how to build access tokens:

- with meaning - current method (using encryption/signature)

- opaque - allowing verification and all the additional operations

Regards,

Robert

--
You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.
To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/z7Oz3ijsF44J.
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.

[Robert Mircea]

Hi Andrew,

Thanks for the reply. Storing every token emitted is not so bad as a solution. Certainly you can use fast stores like Redis or MongoDB to handle this kind of scenarios. Even Oracle at the office can handle several thousand INSERT/UPDATE ops per second and we are not even close in that range of throughput.

Taking your word for "If you're fine to store all access tokens at the auth server, I think you've got everything you need already", we've started implementing an ASP.NET MVC solution which will handle the scenarios that I described. Momentarily, we try to implement token storage in an external database (Oracle) but I don't seem to find a method of how to access it after it has been generated by the framework. Can you point me in the right direction in the API where I can get hold on to the access token in order to store all its info? 

Regards,

Robert

To unsubscribe from this group, send email to dotnetopenid+unsubscribe@googlegroups.com.

[Andrew Arnott]

In reviewing the code, it appears that currently the only way to get at the serialized access token itself is to intercept the result of AuthorizationServer.HandleTokenRequest and AuthorizationServer.PrepareApproveAuthorizationRequest (after calling Channel.PrepareResponse) and reading the HTTP response data. Since OAuth 2 specs out how the access token is to be returned, the format will remain the same and you'll know where to find the access token.

In the future, I can see us making the interfaces public that will make it easier to simply retrieve it as a property from the response objects.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/VftADUMC81UJ.

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]

Have you filed an issue at https://github.com/dotnetopenauth/dotnetopenauth/issues to track this?  Otherwise it's unlikely to happen.  It sounds like a good candidate for v4.2 (the next minor release).

On Monday, July 23, 2012, Karthik Nagaraju wrote:

Hi Andrew,

Do you have any time lines on making the IAccessTokenCarryingRequest interface public (I guess this is the one which allows to get hold of access token, if we have needs to persist it)

 

Thanks Robert for this question, we have similar needs :)

 

-Karthik

On Sunday, July 1, 2012 1:57:49 AM UTC+8, Andrew Arnott wrote:

In reviewing the code, it appears that currently the only way to get at the serialized access token itself is to intercept the result of AuthorizationServer.HandleTokenRequest and AuthorizationServer.PrepareApproveAuthorizationRequest (after calling Channel.PrepareResponse) and reading the HTTP response data. Since OAuth 2 specs out how the access token is to be returned, the format will remain the same and you'll know where to find the access token.

In the future, I can see us making the interfaces public that will make it easier to simply retrieve it as a property from the response objects.

On Thursday, June 28, 2012, Robert Mircea wrote:

Hi Andrew,

Thanks for the reply. Storing every token emitted is not so bad as a solution. Certainly you can use fast stores like Redis or MongoDB to handle this kind of scenarios. Even Oracle at the office can handle several thousand INSERT/UPDATE ops per second and we are not even close in that range of throughput.

Taking your word for "If you're fine to store all access tokens at the auth server, I think you've got everything you need already", we've started implementing an ASP.NET MVC solution which will handle the scenarios that I described. Momentarily, we try to implement token storage in an external database (Oracle) but I don't seem to find a method of how to access it after it has been generated by the framework. Can you point me in the right direction in the API where I can get hold on to the access token in order to store all its info? 

Regards,

Robert

On Monday, June 18, 2012 4:58:46 PM UTC+3, Andrew Arnott wrote:

Hi Robert,

I think your scenarios are quite valid.  I believe you can accomplish them regardless of the access token format, however.  I'll suggest how, and then I'd like to know whether you agree.

Although it's outside the scope of the spec, OAuth 2 resource server can forward each access token they receive to the authorization server to confirm that they are still valid.  This sounds like it's exactly what you're trying to do already, so I suppose you already have a plan to support such a service at the authorization server (just a simple URI endpoint that takes a POST whose payload is the access token, and responds with a valid/invalid response is probably sufficient).

The remaining bit is how your authorization server determines whether its valid or not.  There are at least a couple options here.  One is that your authorization server actually records every access token it generates in a database, removing them as they expire or upon revocation.  Then it's a simple lookup test to respond to the resource server.  It seems that should work with DNOA as it is today.  But it also means you have to store every single access token.  A perhaps superior implementation would be for the authorization server to also be able to decrypt the access token so that it can see the client_id/user/scope/date tuple and thereby determine whether the underlying authorization has been revoked.  This is precisely how the authorization server already determines the revocation/expiry status of refresh tokens, and allows for the auth server to not store any tokens at all.  

To summarize: If you're fine to store all access tokens at the auth server, I think you've got everything you need already.  If you'd rather not store them but still want revocations to be effective immediately (instead of when the access token expires) then we need DNOA auth servers to be able to decrypt access tokens.  

If we didn't rely on cryptography for access tokens to be self-describing, you'd absolutely have to store all access tokens.  Is there any scenario I've missed?

--
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

On Sun, Jun 17, 2012 at 2:45 AM, Robert Mircea <robert...@gmail.com> wrote:

Is there any chance to support an alternative generation method for access_tokens so that they do not use public key encryption/signature and instead they are verifiable by direct access to Authorization Server from Resource Server? I understand t

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/4gmBgGiHECMJ.

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.

[Karthik Nagaraju]

Thanks, have got the request posted there. When can we expect 4.2 release :)?

 

https://github.com/DotNetOpenAuth/DotNetOpenAuth/issues/184

 

-Karthik

To unsubscribe from this group, send email to dotnetopenid+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

[Andrew Arnott]

No timeline has been set.  It's probably a few weeks out.  But depending on your mood, this particular issue may be fixed earlier than that and in that case you could snag it from the nightly builds before the release.

--
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

--

You received this message because you are subscribed to the Google Groups "DotNetOpenAuth" group.

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/iiXtRR1fNc8J.

To post to this group, send email to dotnet...@googlegroups.com.

To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.