Authorization-Server 0 response when ran. about oauth2orizerecipes HOT 6 CLOSED

I get that whenever I don't first go to https://localhost:3000 and click on "Proceed" after getting a warning error about the SSL cert. Try that, then try to use the Rest Advanced Client again.

I'm using a self signed cert (which you have to change out for your own cert that isn't self signed for production). Whenever you try to do a post within Chrome using Rest Advanced Client but you haven't first clicked "proceed" within chrome at https://localhost:3000 or it will refuse to talk to the server.

from oauth2orizerecipes.

Duh. Thanks Frank not sure where my head is today
On 2013-09-25 10:46 AM, "Frank Hassanabad" [email protected] wrote:

I get that whenever I don't first go to https://localhost:3000 and click
on "Proceed" after getting a warning error about the SSL cert. Try that,
then try to use the Rest Advanced Client again.

I'm using a self signed cert (which you have to change out for your own
cert that isn't self signed for production). Whenever you try to do a post
within Chrome using Rest Advanced Client but you haven't first clicked
"proceed" within chrome at https://localhost:3000 it will refuse to talk
to the server.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-25091414
.

from oauth2orizerecipes.

that works. now next question about refresh tokens:

So I took the refresh token and did the grant_type=refresh_token&refresh_token=blahblahblah' and got back a new access_token, expires and token_type..... but I didn't get another refresh token with it, was I supposed to? I even tried adding the scope=offline_access to the refresh token call...

from oauth2orizerecipes.

You're not suppose to get back another refresh token. The refresh token is only meant to get another access token to use to call your endpoints.

OAuth2 of course is a very open ended framework spec which lets you bend the rules in almost any direction. So you can decide when and how to invalidate your refresh tokens. The same also applies to access tokens. An example is that some applications will use never expiring access tokens and not use refresh tokens altogether.

Others such as Google will restrict the number of refresh tokens,

Note that there are limits on the number of refresh tokens that will be issued; one limit per client/user combination, and another per user across all clients

https://developers.google.com/accounts/docs/OAuth2WebServer#offline

I don't place limits or give options (yet) on refresh tokens but you could easily write that code in. You could also write in code that lists all of your access and refresh tokens to an admin through a web page so they can revoke them as they need.

A good rfc to browse is the OAuth2 thread model. That lists a lot of scenarios to help decide how much security you might want (or not):
http://tools.ietf.org/html/rfc6819

from oauth2orizerecipes.

Oh I get it now. Thank you.
On 2013-09-25 11:30 PM, "Frank Hassanabad" [email protected] wrote:

You're not suppose to get back another refresh token. The refresh token is
only meant to get another access token to use to call your endpoints.

OAuth2 of course is a very open ended framework spec which lets you bend
the rules in almost any direction. So you can decide when and how to
invalidate your refresh tokens. The same also applies to access tokens. An
example is that some applications will use never expiring access tokens and
not use refresh tokens altogether.

Others such as Google will restrict the number of refresh tokens,

Note that there are limits on the number of refresh tokens that will be issued; one limit per client/user combination, and another per user across all clients

https://developers.google.com/accounts/docs/OAuth2WebServer#offline

I don't place limits or give options (yet) on refresh tokens but you could
easily write that code in. You could also write in code that lists all of
your access and refresh tokens to an admin through a web page so they can
revoke them as they need.

A good rfc to browse is the OAuth2 thread model. That lists a lot of
scenarios to help decide how much security you might want (or not):
http://tools.ietf.org/html/rfc6819

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-25141574
.

from oauth2orizerecipes.

everything is working as it should. Thanks Frank.

from oauth2orizerecipes.