-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
A couple of questions #506
Comments
Hi Adam, The JWT access token can be stored either in a cookie or with JavaScript The refresh token as you suggest can be used to get a new access token when If you explode the JWT token on the . character, then base64 decode the The site http://jwt.io is quite useful for inspecting JWT tokens. I hope that helps, Alex
|
Great, thanks. So I will store the JWT in a cookie over a secure connection.
Does that sound doable? PS. Hope Tokyo is treating you well :) |
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! |
Have merged your PR; thanks! |
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:
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.
The text was updated successfully, but these errors were encountered: