I save tokens obtained through authorization and use them for post and similar requests. However I need to know when to re-login in case of token expiration.
Does scribe throw any relative exception ? Judging by the sources it doesn't but maybe it throws any other ? Maybe you can suggest a better way ?
Scribe can't tell if a token is expired or not. There's no standard way in OAuth for the provider to inform you that a token was valid and now it isn't.
It's kind of logical that it works that way, tokens have a life span and after that they become rubbish. There's no way of differentiating between a just-expired token and a random string.
The only way you can check is (surprise!) making a request and seeing if it works. Your client can keep some kind of state to check wether the request is getting an unauthorized response with a previously valid token and in that case try to reauthenticate but, sadly, there's no way the provider (or scribe for that matter) can make that easier for you. Sorry.
Related
Stack: React, tRPC, Redux Toolkit
So I'm trying to build out my auth in a way that's somewhat secure and can handle persistent logins. The best approach I've found so far is to have a short-lived JWT that authenticates the user, and then a refresh token with a key saved on the DB that allows new short-lived JWTs to be generated. The short lived token would be stored in my Redux store, while the refresh token would be saved as a cookie so it can be used to log in the user when they refresh the page.
So my first question is, is this in general a good way to approach this problem? I see conflicting answers sometimes.
The second problem I'm facing is that if I want to use a refresh token, I'm going to have to check and see if the JWT is not expired before each API call, and if it is, hit the /refresh endpoint and use the new JWT. However, with my current stack, I'm not sure how to do this in away that doesn't involve a lot of copy and paste code.
The only solutions I've been able to think of so far are:
Just include both JWT and refresh token in every API call. Always send back either the same JWT or a new JWT. If the refresh token is expired, send back a 401.
Do something to so that before every thunk is dispatched, check the JWT/refresh token and hit /refresh if needed before dispatching.
I'm sure there's a better way to handle this though. Any pointers?
Are you sure that you need the short-lived JWT in the first place? Maybe all you need is a good-old cookie-based session. In fact, what you describe with how the refresh token would be used + the first proposed solution, is pretty much how you would use a session. Unless there is a real need for short-lived JWTs as access tokens, I would get rid of them.
If you decide to stick to access and refresh tokens, then what you describe in solution 2 is not enough. You always need a way of intercepting a 401 response from the API, which indicates that the access token is expired. You should then refresh the access token and call the API again. If the refresh fails with 401, then you know that the refresh token is expired. The expiration check needs to be done on the backend because only there you are sure of the clock settings. Clients can have their clocks skewed which makes verifying expiration time on the client side useless.
I didn't make such decisions with implicit flow (I know it's not so good to use it), but I currently have situation where I have to validate my access token on backend(Java 8). Is it okay for every request with access token additionally call oidc provider to check if token is active(not revoked, with valid lifetime) or there is more appropriate way how to handle it? Anyway thanks
I'm kind of surprised that, after searching for this for a while, I didn't find as many answers as I thought would be out there (well I found none), so maybe by asking it here we can help improve search results.
I'm building a REST api which has JWT-based authentication. There is an /auth/login route which returns the token after login/password verification, and the token is subsequently sent in every route in a Authorization http header.
Not, suppose that someone queries another route (say, /cars), without sending the token (that is, before logging in). If I return a 401 unauthorized, I can make the frontend query /auth/login to get the token.
But, strictly speaking, this does not conform to the REST specification, because every resource should be discoverable from the initial one, and a client accessing /cars and receiving a 401 will not know about /auth/login.
So another option would be a redirection like 302. But this semantics means that the resource was temporarily moved, and this is not the case (the resource is still /cars, you just need to authenticate first).
So, what is the correct way to do this procedure in a "true" rest api?
I 100% agree, and that's why I proposed this standard:
https://datatracker.ietf.org/doc/html/draft-pot-authentication-link-01
The idea is that for cases like this, you should be able to return a Link header with an authentication rel, so the client can discover how to proceed.
If I use JHipster + JWT and log in with wrong data for the first time, I get an error message (this is correct, of course). Unfortunately, I can't find where the authentication(user/password check) takes place.
The client calls'api/authenticate' and lands in the JWT filter. jwt does not yet exist here. And so it goes on in the chain.There are now 12 spring filters, but unfortunately I haven't found the check in any of them.
The'DomainUserDetailsService','UserJWT-Controller' are not called.
Question: Does anyone know where the authentication happens?
Thanks for the answer in advance
It's done in the AuthenticationManager which is built in SecurityConfiguration.java and uses DomainUserDetailsService
This is called when sending a POST to /api/authenticate which is handled by UserJWTController
I suppose you only looked at GET on /api/authenticate in AccountResource.java which is used only for checking that user is authenticated with a token.
I am a fair way through implementing an actionscript OAuth library which I am initially testing with Google's Drive Api.
I know how you are supposed to refresh an access token using your refresh token but my question is how do I test it?
How do I make my access_token expire so that I test my code that catches the error, attempts a refresh and then re-loads the initial request? If I can only do this once a week (or however often they expire) it's going to take a while to get it right!
Thanks
If you're looking to test your code, you don't actually need to invalidate or expire the access token. Simply make a (say) Drive call with a null access token and you will receive the same 401 response that you would have got with an expired access token.
Well, judging by the lack of responses to this question I am assuming that there is no way to do this.
This page:
https://developers.google.com/youtube/v3/guides/authentication#installed-apps
describes how to revoke an access or refresh token by using this url:
https://accounts.google.com/o/oauth2/revoke?token={token}
but then says:
The specified token can be an access token or a refresh token. If the token is an access token and it has a corresponding refresh token, the refresh token is also revoked.
So if you just want to revoke an access token you aren't able to.
I think the only solution is to wait for the access token to expire (seems to take an hour) then go about testing your app.
I'll be very happy if anyone tells me a faster way to make the token expire.
I handle this testing by simply making note of an expired access_token. Then when I need to test how my app deals with an expired token I simply give the app that expired token to work with. This way, for example, I can test that requests with an expired token will fail as expected.
The easiest way of doing it is using the OAuth Playground 2.0
https://developers.google.com/oauthplayground/
In step 2 especially, you can try refreshing your access token with a refresh token.
Additionally, in the setting (the gear icon), you can set up your own OAuth Credentials to test it out for your own API project.
Im using nodemailer. When setting the options for the transporter object, you can specify an 'expires' time. There isn't any documentation I found on that option but I'm sure you can figure it out. :)
I haven't found a way to shorten the expiration time on an access token either.
In fact you can't even generate another refresh_token unless you revoke access. I don't think you can generate another refresh_token even if you let the access token expire, although I have to wait an hour to test this.
I did find out that if you send the refresh_token and the authorization token is still active, you just get the same live token back although the expiration time is reset.