Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refresh Tokens #1

Closed
ghost opened this issue Sep 6, 2013 · 5 comments
Closed

Refresh Tokens #1

ghost opened this issue Sep 6, 2013 · 5 comments
Labels

Comments

@ghost
Copy link

ghost commented Sep 6, 2013

Hi there Frank. This is plaguing me for quite sometime, I do not understand how refresh tokens work. Can you give me an example, or a gist? How does it apply from the client side app?

I have a SPA AngularJS app, with no backend, using Oauth2 API server to communicate, so far, in pre-beta I have just been using really-long-lived tokens from Oauth2Orize, but now it's coming up to launch and I need to make sure I can do refresh tokens..

Think you can point me in the right direction, maybe even an example so I can better understand?

@FrankHassanabad
Copy link
Owner

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.

@ghost
Copy link
Author

ghost commented Sep 7, 2013

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?

@FrankHassanabad
Copy link
Owner

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?

@ghost
Copy link
Author

ghost commented Sep 7, 2013

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.

@FrankHassanabad
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant