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.

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.

I'm trying to send the following request:

   1. code:

   osmx!IAAAAAcO7RimcT8czYqaKnlte-AkHoJko5KuP9Wqlx8KEz4SIQEAAAG0T82ZqqBR7kJ2Kc 4N_R5wclDMnnV59jbgl7Cyr-Z1Z60Z8vF9DhVEVhVD7-cy88CRNgyzLCnfgghsdSXbwp8xywIeR 53f-YTgrG0KU_uu_HXVn896tV-zbF4h8QcgZpEB79JWih2oAeIdShalA95vP-YYqRNFlrOWOcXI HQ2xfYZqFAxC--UVG5EeAy8NW5Hup0gKmeChS_ibyadPz8l3uAbQOTecCc21TGDBhpNJnCXp_P7 YaQclsTvRkYzb57EVOHEpcp3cooiknYD_2l9uhCoC-O8igGvYzRd0oi02uaeFFg3VfsO1hCtPOI rnI6DDrEXwgRpkAtbFnSNLsQE4hqTO5upNljdrYoR45tHZ-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?

Turn on logging <http://tinyurl.com/dnoalogs> 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

On Tue, Jul 24, 2012 at 8:24 PM, Aleksander Heintz <alxa...@alxandr.me>wrote:

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 <alxa...@alxandr.me>wrote:

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.Proce ssIncomingMessage(IProtocolMessage
message)

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

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.

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 <alxa...@alxandr.me>wrote:

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?

I think that sounds like a reasonable approach.

Sent from my Windows Phone
------------------------------
From: Aleksander Heintz
Sent: 7/25/2012 10:20 PM
To: dotnetopenid@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?

--
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.
To post to this group, send email to dotnetopenid@googlegroups.com.
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.

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?

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.
On 2012-07-27, at 2:49 AM, Aleksander Heintz wrote: