A couple of questions

[assembledadam]

Hello! I'm using the version 5 RC1 of the lib and am integrating it with a Laravel web app. I realise there is a laravel project using this lib, but am doing this manually as I want control over my storage.

I'm using the Password grant type as I have an app with users that sits on top of an API. The app is a client of the API. Users login via the app which sends the request for an access token with the app client credentials to the APIs auth endpoint. If verified, the app gets an access token (in the form of a JWT).

2 primary questions:

• How do you think I should maintain user sessions between page requests? Looking at JWT, it contains key info, so I'm thinking maintaining the state on the server side (like a traditional session-system) might not be necessary (if the JWT is stored in a cookie)?
• Despite using the Password grant i'm still given a RefreshToken on successful authentication. Does this mean I don't need to implement the RefreshToken grant to make use of its functionality? Or do I need to initialise that grant too in order to make the RefreshToken request?

By the way, my understanding is that RefreshToken exists to e.g. prevent app users from needing to re-authenticate within a given timeframe - is that a fair approximation? (figured this out)

Rather new to OAuth in general so any help would be appreciated.

[alexbilbie]

Hi Adam,

The JWT access token can be stored either in a cookie or with JavaScript
using client local storage. The JWT is signed with the auth server's
private API key so it can't be tampered with.

The refresh token as you suggest can be used to get a new access token when
the old one expires. You just need to enable the refresh token grant on the
auth server alongside the password grant.

If you explode the JWT token on the . character, then base64 decode the
second (of three) array items, then JSON decode that string you can see the
expiry time (unix timestamp) of the access token so you can pre-emptily
refresh it.

The site http://jwt.io is quite useful for inspecting JWT tokens.

I hope that helps,

Alex
On Thu, 31 Mar 2016 at 04:34, Adam McCann [email protected] wrote:

Hello! I'm using the version 5 RC1 of the lib and am integrating it with a
Laravel web app. I realise there is a laravel project using this lib, but
am doing this manually as I want control over my storage.

I'm using the Password grant type as I have an app with users that sits on
top of an API. The app is a client of the API. Users login via the app
which sends the request for an access token with the app client credentials
to the APIs auth endpoint. If verified, the app gets an access token (in
the form of a JWT).

2 primary questions:

• How do you think I should maintain user sessions between page
  requests? Looking at JWT, it contains key info, so I'm thinking maintaining
  the state on the server side (like a traditional session-system) might not
  be necessary (if the JWT is stored in a cookie)?
• Despite using the Password grant i'm still given a RefreshToken on
  successful authentication. Does this mean I don't need to implement the
  RefreshToken grant to make use of its functionality? Or do I need to
  initialise that grant too in order to make the RefreshToken request?

By the way, my understanding is that RefreshToken exists to e.g. prevent
app users from needing to re-authenticate - is that a fair approximation?

Rather new to OAuth in general so any help would be appreciated.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#506

[assembledadam]

Great, thanks. So I will store the JWT in a cookie over a secure connection.

• What would be wrong with letting the refresh token do its thing rather than pre-empting and refreshing it? Or rather, what advantage does it give me to pre-empt it?
• In order to maintain the state of the user, I also need to store their ID in the JWT. I'm guessing the provision for this exists in the lib - as you've got a User entity with an identifier. Presumably the User ID here is the sub/aud fields in the JWT payload?
• Assuming that's right, Unless I'm missing something, I don't need any kind of persistent server-side state tracking the app's users - which would be lovely:
  1. Grab token from cookie and place it in the request header
  2. Run the validateAuthenticatedRequest(), do any refresh actions deemed necessary (or not, if I just leave it for the refresh token and your lib)
  3. Extract the User ID from the JWT token (either via one the oauth libs methods if I can find one or failing that, manually)
  4. If the User ID > 0, they are logged in - grab their user info, and using that determine if the scopes associated with their user group have permission for this requested http method/route.

Does that sound doable?

PS. Hope Tokyo is treating you well :)

[assembledadam]

Also on a side note, I'm playing around with the lib - i've generated a token using the password grant, and then I'm using that token to access a protected resource.

The thing is, the expiry time of the issued token (exp field) is in the past, but it's still letting me through.

Isn't validateAuthenticatedRequest() within ResourceServerMiddleware supposed to pick that up and deny the user? Or do I need to implement my own code to detect expired tokens?

Thanks!

Edit: looking at the code for oauth2-server - BearerTokenValidator (which uses lcobucci/jwt for validation), there appears to be nothing that validates that the the current time is before the 'exp' value. Only the token is verified, checking the signature, rather than actually validating its 'claims'. Given this is a requirements when 'exp' is specified in the RFC I must be missing something or this is a bug :)

Edit2: It's not just my code, in all of the examples the lib doesn't respect the expiry time and allows unlimited access once a token has been generated

Edit3: Just submitted a PR that fixes the token expiry issue. I'm guessing I'm missing something here because somebody MUST have noticed this before to get to RC1 otherwise. 3am in Tokyo right now, sweet dreams!

[alexbilbie]

Have merged your PR; thanks!