OAuth2 roling expiration or refresh_token

[Aleksander Heintz]

I'm currently writing a webpage (front-end and back-end) which exposes a OAuth2 enabled API.

I'm already able to generate the tokens, and once I have a token I can get to the "protected" resources (given that I have valid scopes ofc.)

However, the problem comes when I access my page in the browser (which is to be the main client for consuming the OAuth2 API).

For testing purposes I've made the token short-lived (2 minutes), and the problem is that once those two minutes are up, the client is kicked out of the system, and cannot access his private resources anymore.

Now, if there were a 2 minutes delay without any requests using the token, this would be ok, however, since the client has been activily using the service since the token was issued, he should not be booted out.

Just imagine if you went to facebook (or any other page you log into), and after half an hour you were logged out regardles of what you had been doing up till then. If you had done nothing, you might have understood it,

but if you were in the middle of answering some comment to a post you just posted, then it would feel rather strange.

So what I need is a way to renew the token, or a way to make the expiration roling, and I have no idea how to do either. Also, there might be better ideas on how to solve this problem that I have not thought about at all, so if you have any other ways of solving this, please do tell.

[Andrew Arnott]

Hi Alek.,

The OAuth 2 spec supported answer for this is to use refresh tokens to obtain new access tokens as the access tokens approach their expiration.  I believe DNOA may not yet support refresh tokens for anonymous clients (I take it your client is running in the browser), but you can certainly try the auth code grant flow from javascript and see if it works and let us know what you find.  If it's not supported yet, we're interested in adding it.

--
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/-/cuTieHJp9JgJ.
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

[Aleksander Heintz]

I'm trying to send the following request:

1. code:
   osmx!IAAAAAcO7RimcT8czYqaKnlte-AkHoJko5KuP9Wqlx8KEz4SIQEAAAG0T82ZqqBR7kJ2Kc4N_R5wclDMnnV59jbgl7Cyr-Z1Z60Z8vF9DhVEVhVD7-cy88CRNgyzLCnfgghsdSXbwp8xywIeR53f-YTgrG0KU_uu_HXVn896tV-zbF4h8QcgZpEB79JWih2oAeIdShalA95vP-YYqRNFlrOWOcXIHQ2xfYZqFAxC--UVG5EeAy8NW5Hup0gKmeChS_ibyadPz8l3uAbQOTecCc21TGDBhpNJnCXp_P7YaQclsTvRkYzb57EVOHEpcp3cooiknYD_2l9uhCoC-O8igGvYzRd0oi02uaeFFg3VfsO1hCtPOIrnI6DDrEXwgRpkAtbFnSNLsQE4hqTO5upNljdrYoR45tHZ-wdI9DSKbgpe4q-IE3VaLvU
2. client_id:
   0C9D7AA1-99FA-4C99-A908-F47636D0AEBA
3. client_secret:
   5DE78BE0-D140-41E6-92A8-382E87E0D0DF
4. redirect_uri:
   https://samples.alxandr.me
5. grant_type:
   authorization_code

However, I keep getting 400 Invalid Request. I'm no expert when it comes to OAuth, so I don't know if the request is wrong or not, but I do know that the code is what I got from the server, and the client_id and client_secrets are correct, as is the redirect_uri. The only code run on the end-point is this:

return this.authorizationServer.HandleTokenRequest(this.Request).AsActionResult();

Any idea what I'm doing wrong?

[Andrew Arnott]

Turn on logging and see what your auth server says.

--
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/-/I6AGmiTjU8YJ.

[Aleksander Heintz]

Yeah, well, I can't get logging to work. I've tried both glimpse and log4net, and glimps shows me nothing, and log4net generates no log-files.

[Andrew Arnott]

OK.  Well, I'll take a closer look at your request message in the morning and see if I can figure out what might be going wrong.

--
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 Tue, Jul 24, 2012 at 9:39 PM, Aleksander Heintz <alx...@alxandr.me> wrote:

Yeah, well, I can't get logging to work. I've tried both glimpse and log4net, and glimps shows me nothing, and log4net generates no log-files.

--

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/-/qDRrs49FrhkJ.

[Aleksander Heintz]

I figured out the logging :), I just had to change the config (I had just coppied and pasted from the link you just sent me). Anyways; I get this:

2012-07-25 06:57:41,768 (GMT+2) [51] ERROR DotNetOpenAuth.Messaging - Protocol error: redirect_uri_mismatch

And I get it even though I go into my db and copy paste the redirect uri of the client (just to make sure I didn't misspell any).

The top of the stack looks like this:

   at DotNetOpenAuth.Messaging.ErrorUtilities.VerifyProtocol(Boolean condition, String unformattedMessage, Object[] args)

   at DotNetOpenAuth.OAuth2.ChannelElements.AuthorizationCode.VerifyCallback(Uri callback)

   at DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement.ProcessIncomingMessage(IProtocolMessage message)

[Aleksander Heintz]

Looking at the source-code of  DotNetOpenAuth.OAuth2.ChannelElements.AuthorizationCode.VerifyCallback I figured out what URI it was expecting, and I'm now able to get a response using the server-side flow. The response also contains a refresh_token that I'm about to test how works. However, there are one thing I don't like about this solution, and that is that I have to "give away" my secret to the public... I'm not sure what this signifies though, it's just the word "secret" that makes it sound like something I maybe shouldn't do...

[Aleksander Heintz]

Ok, for those of you who are wondering, DNOA supports refresh_tokens out of the box (I didn't need to do anything except switch to authorization_code instead of token request). The downside, as I said in my previous post is that I have to give away my secret key. I'm currently thinking of ways to solve this on the server-side, so that users going to my website in the browser; though my website only can get tokens without a client_secret beeing presented. This will probably be solvable through some antyforgery sessions, in combination with the token-request.

[Andrew Arnott]

Good progress. As for a client secret, I take it you're saying that your javascript client has to have a secret to get an authorization code, is that right?  If so, that's the bit that the OAuth 2 recent drafts recently allowed to happen, and DNOA hasn't been updated to account for it yet.  Anonymous clients be allowed to be issued refresh tokens if it complies with the required security of the host, which in this case it sounds like you're happy with. 

I want to call out that anonymous clients that can be issued refresh tokens can lead to new security exploits.  For example, if I can get your user to enter their password just once, I can get a refresh token, and thereby gain access to that user's data, and be immune to that user changing their password in order to cancel my access.  So you may want to establish some kind of inactivity timeout for authorizations granted to anonymous clients so that refresh tokens become unusable.  You could also cause that any password changes automatically also revoke authorizations to anonymous clients.

--
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 Tue, Jul 24, 2012 at 11:07 PM, Aleksander Heintz <alx...@alxandr.me> wrote:

Ok, for those of you who are wondering, DNOA supports refresh_tokens out of the box (I didn't need to do anything except switch to authorization_code instead of token request). The downside, as I said in my previous post is that I have to give away my secret key. I'm currently thinking of ways to solve this on the server-side, so that users going to my website in the browser; though my website only can get tokens without a client_secret beeing presented. This will probably be solvable through some antyforgery sessions, in combination with the token-request.

--

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/-/ia8pTzat-RsJ.

[Aleksander Heintz]

As far as I can tell you don't just need the secret to get the autorization-code, but also for exchanging a refresh_token for a access_token...

[Aleksander Heintz]

I was thinking. What I have my server generate a refresh_token (doing the server-side OAuth2 flow to itself) during a Forms login? That wouldn't be any more insecure than normal websites (without API access). I don't even have to give the client the refresh_token, I can just store it in session and setup an endpoint for getting new access_tokens given that the refresh_token is stored in session. How would that be for safty measure?

Also, I have no idea on how to withdraw refresh_tokens generated by DNOA, nor do I know when users changes passwords or the likes, cause I use openID to login; though I do know what client's they have granted access to, and can give them the ability to withdraw that. That would make the "IsAuthorizationValid" return false.

[Andrew Arnott]

I think that sounds like a reasonable approach.

Sent from my Windows Phone

---

From: Aleksander Heintz
Sent: 7/25/2012 10:20 PM
To: dotnet...@googlegroups.com
Subject: Re: [dotnetopenauth] OAuth2 roling expiration or refresh_token

I was thinking. What I have my server generate a refresh_token (doing the server-side OAuth2 flow to itself) during a Forms login? That wouldn't be any more insecure than normal websites (without API access). I don't even have to give the client the refresh_token, I can just store it in session and setup an endpoint for getting new access_tokens given that the refresh_token is stored in session. How would that be for safty measure?

Also, I have no idea on how to withdraw refresh_tokens generated by DNOA, nor do I know when users changes passwords or the likes, cause I use openID to login; though I do know what client's they have granted access to, and can give them the ability to withdraw that. That would make the "IsAuthorizationValid" return false.

--

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/-/HvM1DahvbtIJ.

[Aleksander Heintz]

http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/

that was fairly dishartening tbh

Seems maybe I should switch to oauth 1 and all my problems go away?

[John Bradley]

With OAuth 1 you will have even more problems as the one of the things OAuth 2 added and Eran objected to was bearer tokens for a canvas app.

The code flow is intended for servers.  If you have no security on the secret you may as well just use the token flow and make the tokens long lived.   The user still has the ability to revoke them.

What a number of people like AOL are doing is keeping track of the session state and expiring the access token after the session expires and the user needs to log in again anyway.

John B.

--
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/-/dlxd2VTJv24J.