I'm starting to learn the Laravel passport API. I tried to use my tokens and it works fine.When I revoke the specific token it works fine too, it shows the proper output that says
{
"message": "Unauthenticated"
}
But when tried to use the token that is expired 1 day ago. It still authenticated which means doesn't do the same message when I put revoke on it.
I'm having the same problem in this thread:
https://laracasts.com/discuss/channels/laravel/passport-not-erroring-on-expired-token?page=1
I'm thinking if there's another or tricky way how to check the expiration date of the specific token in the backend part. Recently I found an alternative way to validate the expired tokens. Which is the task scheduling of laravel. Where every minute the system will check if there's a token expired so that it will automatically update its revoke field as true. But I doubt this solution so that I'm still trying to find some other options.
I think I found the problem probably.
You must set the expiration time in AuthServiceProvider by adding Passport::tokensExpireIn(); to boot section and token won't be validated after this time but the problem is the token won't be revoked automatically and i don't get it why.
Maybe revoke is not for being set by passport and its only for us
Related
So far I have created a database with
user_id,token.
It stores all the logged in user's token.
I have fetched all the tokens from database by user_id. Then loop through,
JWTAuth::invalidate(new \Tymon\JWTAuth\Token($token->token));
Its not working.
Third party package: Tymon Laravel JWT
How to achieve this functionality?
Just adding here the comment of Harpal singh.It solved my issue.
"you can create a middleware to check if account is deactivated then add
JWTAuth::invalidate(new \Tymon\JWTAuth\Token($token->token));
to invalidate the user. By doing this if deactivated user trying to access routes, he will not get access."
After long time for trace the source code. I found this works.
JWTAuth::manager()->invalidate(new Token({YourToken}))
I am using JWT for the first time, I am finding a hard time to understand the way it works fully, every time I find a solution to simethong, an other thing pops out.
I was trying to authenticate before and when I send the correct username and password I get a token when using Postman.
I left the project few hours and came back and now when I try to authenticate I get this error :
{
"code": 401,
"message": "Expired JWT Token"
}
I don't know how to solve it, because I did not knwo I may face such problem.
Any help would be much appreciated.
It goes like this:
You make first api request, pass your credentials, get token and store it somewhere.
After that you should pass that token (trough "Bearer" header field) with every other request so server could identify you.
But that token won't be valid forever. After some time (TTL) it will expire and you'll get message like that. Then you have to repeat authentication to get new token.
So just repeat request you made at start, pass again credentials, collect and store again new token and keep using it as before.
If you're using LexikJWTAuthenticationBundle, you can set the TimeToLive for JWT in lexik_jwt_authentication.yaml in config/packages.
The token_ttl: attribute is for setting up the TimeToLive of a token in seconds (e.g., 604800 is equal to 7 days).
I've been working on this for 3 days now, trying various methods, hunting through the gmail api docs and stackoverflow, but I'm still not sure if it's even possible.
I'm trying to send email with the gmail api in a cron-style process. (not literally cron, but similar). So there is no user interaction.
I set up credentials on the https://console.developers.google.com/apis/credentials page, but when I try to use it, I get errors. I also ran the quickstart.php from https://developers.google.com/gmail/api/quickstart/php#step_2_install_the_google_client_library but that seems that the credentials it creates expire after 3600 seconds. I'm also not even sure how to use those as it doesn't have similar keys as the other credential file.
And then I saw on the credentials page, if you try to create a new set of credentials for the gmail api, for a cron-job, it won't let you. It simply says "User data cannot be accessed from a platform without a UI because it requires user interaction for sign-in."
My question is, is it even possibly to run a cron job to send email with the gmail api without building my own classes that implement curl to read and scrape web pages?
Edit: I appreciate everyone's help but I'm just looking to see if anyone has actually done it. So far, no one's admitting it. I've looked at the service level credentials. I've looked at the user level credentials. I've tried the quick-start. The quick start works, but even using the result immediately to send an email fails with a login failure.
I've read the documentation about refreshing the key as well.
It just seems to me that google has made so much available to the api that they may have forgotten doing anything without user interaction. Hey, I get it. Trying to write for everything is complicated. I'm not complaining. I'm seriously only asking if anyone can even actually use gmail for this.
You can request an offline access the first time the user logs in and refresh it when the access token expires. You have to ask the user to login the first time though.
First, before generating the login url, you need to set the access type to 'offline'. To do that, add the following line of code before calling $this->client->createAuthUrl().
$this->client->setAccessType($accessType);
That will prompt the user for offline access the first time they're authenticating. Then, in your callback function, you should authenticate the user based on the received code and get the refresh token:
$this->client->authenticate($code);
$tokens = $this->client->getAccessToken();
$refresh_token = $tokens->refresh_token;
Save the refresh_token in your database and you will be able to create new access token every time it expires. You do that with the following code:
$this->client->refreshToken($refreshToken);
Note: This answer is based on Google's PHP SDK and the client is their client object. I created a wrapper for their API that you might find useful and easier for implementation. You can check it here, it has most of the functions covered.
I don't know the the Gmail API specifically but if you are using oAuth to get the credentials there is usually a refresh token that you can use to renew your credentials (basically get a new set) programmaticly. You can read more about it here.
Edit:
You need the UI the first time you get the token information. This can be done by a button in the settings or something that stores the returned info in a permanent place like a database. Then for the 'cron' type calls you reference the access token or if expired use the refresh token to get a new access token.
I created an app that also uses the Google Analytics API. However, I've got the following question:
When I'm asking for an Access Token I'm getting an access token that expires after 3600 seconds. I also got an refresh token that I can use to generate more access tokens later on.
Do I really need to use the refresh token to generate a working access token every hour or is there a way to have a user authenticate once and then always use the same code without going through the expiration trouble?
I want to have a cronjob, and while I know, it's easy to just use the refresh token to obtain a new one, I'm still asking if it's somehow possible to have an access token that lasts forever?
Otherwise I'll just refresh the token when needed.
There is a middle path: You can request the Access Token new on each call rather than use the refresh token.
That simplifies things so you can have just one function to get an Access Token and use it immediately within the cron job. This eliminates needing to store the refresh otken between cron executions.
I am working on integrating Google Apps into my PHP app. I have already a login system that assigns a session ID to a user (after entering username and password), which gets stored in the database when the user is logged in. Session ID's become invalid after a certain time of inactivity (configurable by the user, can be 5 minutes, 15, 60...). That session ID is passed in the url to check if a user is still logged in. When logging out, the session ID is removed from the database.
I let people log in with Google by storing their Google ID in the database, when they log in, I request an access token, query the userinfo, see if the google ID is in the database and if so, assign a session ID to this user. Since I want to be able to query other API's I also store the access token json in the database. When a user logs out, the access token is also removed from the database.
This works, my users are able to log in using their Google account and I can query the API's using the stored access_token, however some things feel clunky of make me feel uncertain about my workflow:
If you force_approval you get a refresh_token, I feel like I should be using this refresh token to get a new access token, instead of removing the old one from the database and entering a new one when the user logs in again. On the other hand, when logging in, I do not know who it is yet, so I don't know which refresh token to use. Maybe I'm misunderstanding what the refresh token is for. Also, I don't really want to force approval every time, so I can't even use the refresh_token in that case.
As said before, users can determine how long their session will last, however, the google access_token always expires after 3600 seconds. It'd be really stupid if users would work an hour on the system and after that the Google API's suddenly fail, forcing them to log in again. The Google OAuth playground shows a checkbox "Auto-refresh token before it expires", but I'm not seeing how to do this. Do I have to use the refresh token here? Or simply request a new token in the background (if I'm not forcing approval)?
At the moment, I'm using the userinfo query (https://www.googleapis.com/oauth2/v2/userinfo) to find the user id, but I can also use the tokeninfo (https://www.googleapis.com/oauth2/v1/tokeninfo). Tokeninfo is not listed in the oauth playground, but the result does show how long the token remains valid (however, I can also calculate this myself). Is one preferable over the other?
I'm storing the entire json object in the database (access_token, id_token, expires_in and token_type) but I feel my app will still work perfectly if I only store the access_token (only problem I foresee is if the expires_in time changes). Do I need to store the id_token for example?
I find the Google documentation (at developers.google.com) sometimes very lacking, if anyone knows any other good sources of information, I'm interested in them as well.
I think it might help if you took a look at the lastest OpenID Connect Specs where concepts like the userinfo endpoint come from. OpenID connect is built on top of OAuth 2. There's quite a lot in there, but it's still probably worth a look. This blog article is also very good (as are others in the same blog).
Unfortunately, I don't think Google's implementation is currently up to date with the latest spec draft so it will probably be a moving target for some time. These things have changed a lot over the past year.
I agree with your first point that you should be obtaining a new access token each time you authenticate a user, rather than refreshing an old one. You don't know who the user is until they have logged in and granted you an access token. In general, the lifespan of an access token is not linked to the user's session. Once issued, your application could theoretically use it to access resources independently of the user's presence. If you want to carry on accessing the resource beyond the token expiry time, then you need to submit the refresh token at that point to obtain a new access token. I'm afraid I don't know what the "auto-refresh" feature is for.
I believe Google's tokeninfo is analogous to the check_id endpoint of OpenID connect, but accepts either an access token or an id token, rather than just the latter. Note that the expiry times of the two may differ. You would typically be able to retrieve more detailed user data from the userinfo endpoint than from check_id, which would normally return the bare user_id.
You shouldn't need to store the id_token. It is a bit like a record of the user's authentication by the authorization server. The access token is what your application will be interested in maintaining once you have validated the user identity.