Refresh Tokens about oauth2orizerecipes HOT 5 CLOSED

Sounds like you're working on an interesting project. Which grant type(s) are you currently using?

With refresh tokens, a good place conceptually to start is Google's explanation of refresh tokens:
https://developers.google.com/accounts/docs/OAuth2WebServer#offline

Of the 4 grant types, only "Authorization Code" and "Resource Owner Password Credentials" are allowed to return refresh tokens. Since the spec does not define the implementation of how to properly request a refresh token, I made it so that if you give a scope=offline_access it will return you a refresh token. This is similar to google's mechanism of "offline" but not the same implementation details since this is Oauth2 and not the open id connect layer which google uses.

I updated my test examples for both those grant types to show how to use refresh tokens:
https://github.com/FrankHassanabad/Oauth2orizeRecipes/wiki/Authorization-code
https://github.com/FrankHassanabad/Oauth2orizeRecipes/wiki/Resource-Owner-Password-Credentials

I also just noticed a bug with my token endpoint when using a refresh token (#2), and fixed it so you will want to do a pull from master.

After reading through that, let me know if you have more questions and I'll be happy to try to answer them.

from oauth2orizerecipes.

I am using the ROPC approach, and I will try and grab your code, and update my code. Thank you for taking the time to update your code. I will let you know sometime today how it goes :)

I have another question... I loaded your Authorization Server last night, and in the Chrome Advanced Rest App, I grabbed myself a token, using ROPC, then I immediately I did a /api/tokeninfo but I got a "invalid token", instead of info about the token.... ? did I not do it right? am I missing something at all?

from oauth2orizerecipes.

I just added this to the wiki for the token info endpoint:
https://github.com/FrankHassanabad/Oauth2orizeRecipes/wiki/Token-Info-Endpoint

That endpoint only validates access tokens and not refresh tokens. I just tried it out with an access token from the Resource Owner Password Credentials and did not get any obvious errors. Is there something I'm missing? A bug somewhere? Set of steps I should try out to see if I can break it?

On a different note (because I'm curious), you're using the ROPC (Resource Owner Password Credentials) with a SPA (Single Page Application). I'm going to take a guess that you have a custom login form in Angular which isn't being served up by the authorization-server. You get the user id and password from the login screen and then exchange it for a long lived access token which you use to make endpoint calls. All correct so far?

My other questions that I'm curious about...

• Did you use ROPC because you didn't want decision screens when you're writing your trusted application?
• How are you storing your client id and client secret to send through basic auth? Is the secret "known"? In other words are you storing them on the client side somewhere? Or are you doing something else?

from oauth2orizerecipes.

All good questions Frank. At this current time, it's a SPA with a node.js backend, in turn we have our own node,js SDK to our API server.

I went the route of ROPC because there is no need for decisions as the OAuth is publicly available, YET.
So ClientID and ClientSecret are in the backend...

However, how I got to this point is, I am re-writing the frontend to be client-side ONLY. meaning the calls to post and get from the api will be done via ajax and the access_token will be publically visible, so I need to properly code in OAuth process.

Have you done this before with AngularJS as that is what I am re-building it in.

from oauth2orizerecipes.

I've seen it done with a few examples. When you say client-side ONLY, could you do client side for everything but the ROPC and initial login? Just inject the ROPC into the web page as it loads after the login and from there do SPA? I have an example called resource-server where I did that as a test to see if it could be done

To run it you run the auth-server,

cd authorization-server
npm install
node app.js

then you run the resource-server,

cd resource-server
npm install
node app.js

Then go to the info page for resource-server

https://localhost:4000/info

You'll get the login prompt. However if you look at the code, you'll see the login is ROPC from the resource-server to the authorization-server.
https://github.com/FrankHassanabad/Oauth2orizeRecipes/blob/master/resource-server/auth.js#L28-L61

And if you look at
https://github.com/FrankHassanabad/Oauth2orizeRecipes/blob/master/resource-server/views/info.ejs#L5

You'll see that I'm injecting the access_token into the page after the login has been completed.

If you use client side pure for ROPC with the login, then your client secret will be open to where any user can look at the HTML source and grab it and use it with other applications to "spoof" fake logins to get users to log into the system. Not a show stopper, really, but not as secure as keeping the client secret, secret. The access_token, of course, is okay to have on the client side just keep it as secure as possible.

Just tossing some ideas out.

from oauth2orizerecipes.