We are currently working with AWS-Cognito and I've been looking over the documentation to find a method that helps me retrieve the information of the user without refreshing the session if the tokens are expired.
According to this post (how handle refresh token service in AWS amplify-js), the currentSession method does refresh the session because it uses the getSession() method under the hood.
This is why I thought of using the currentUserPoolUser() method to get the information about the user's session without refreshing the tokens if they are expired, but I tried it out today and the session still gets refreshed if the tokens are expired with this method.
Does anybody know if there is a method in the aws-amplify library that would help me with this use case?
Thank you to everyone in advance! Have a great day!
Related
I am using the Gmail api to send e-mails from my Oracle database.
After a while, the Oauth2 token expires and the token needs to be refreshed with, using the refresh token.
All of this works fine (in both Postman and Oracle).
When the mail has not been used for a while ( a few weeks) the refresh token doesn't work anymore.
Then I need to get a new authorization code etc. It seems as if the gmail-api revokes its grant after a certain time.
Is there a way to work around this ?
thanks in advance.
Servé
There are a number of things which can cause a refresh token to expire here are my top three.
Applications that are still in testing, and have not bee though the google verification process will have their refresh tokens expired within in two weeks.
If the user changes their password this will also cause a refresh token to expire when using the gmail scopes.
If you authorize the app, then authorize it again you get two refresh tokens both will work, you can have up to fifty outstanding refresh tokens once you have hit that number the first one will be expired, as you can maximum have fifty outstanding refresh tokens.
Have a look at the possible refresh token expiration reasons here: https://developers.google.com/identity/protocols/oauth2#expiration
We have been using Oidc-Client js for SPA application.Below are the clarifications.
We were able to implement signinRedirect but not sure how to implement and handle signinRedirectCallback method to get user and token responses. Hence kindly provide the sample to use the same.
Regarding silent renew token, once it's generated silently then when it expires.
I have some resources on this and a sample that helps with testing of expiry events:
Renewal Code from Code Sample
When the session expires, eg if the user leaves the browser running overnight, you check for a login_required error code
Blog Posts:
SPA Token Renewal
Code Sample Overview
so, long story short, I'm working on my portfolio and I want to retrieve my LinkedIn recommendations from my profile, I googled but all I could find was about retrieving info from logged-in users using OAuth, is there a way to get a personal API key to retrieve my profile's info for everyone to see on my portfolio?
I don't think this is important but I'm using React.
I hope I made myself clear, I'd appreciate your help!
Well, when you do the 2-legged OAuth flow, you receive a response that includes an access_token that you can use to make api requests. Here is the documentation.
So in your react site, whenever you fail the request (which means your access token expired), you can just resend the request and get the new access token. This access token acts like an api key, and the 2-legged OAuth flow can be entirely automated without user intervention. These tokens have a 30 minute lifespan, so maybe you can just set an interval to fire every 30 minutes to refresh the token.
I would like to do social-login with LinkedIn. I am using the very convenient package react-social-login (see demo here : https://deepakaggarwal7.github.io/react-social-login/).
In the demo, and in my implementation, everything works fine, and I am able to retrieve the access-token and expiration-date.
Unfortunately, for LinkedIn, the access-token is instantly expired. You can even test it in the demo.
My question is: do you also retrieve expired access-token ? Is it related to some configuration in LinkedIn API (according to the documentation it expires after 60 days) ?
Many thanks for your help,
Nicolas
so im quite certain that you are talking to a V2 API from linkedin? if this is the case. then your access token is just fine.
the problem with linkedin's API is that a part of it (V2) is just for the partners of linkedin. you can become a partner by requesting it. but it will take you up to a month.
the V1 api is completely free to use after you authenticated a user.
if this is not the case, please provide more information about how you came to the conclussion that the authentication token you get is allways expired. because technically this isnt possible because the linkedin service generates one at the fly.
Hi I'm developing a React app that communicates with an Express API. I'm trying to implement JWT authentication but I don't know what should happen when the jwt expires. It not seems very user friendly if the user is logged out when the token expires.
Should I use refresh tokens? As it says in the node-jsonwebtoken package documentation (jsonwebtoken). This may not be the best approach.
Should I create a new jwt in every request to the server? If the user reads an article for a long time without doing any request, he is going to be logged out.
Maybe I'm wrong and the best practice is using a big expiration time and let the user be logged out. If this is the case what would be a reasonable time?
Thanks!
A pattern commonly used along with refresh tokens is to follow a workflow along the lines of:
Some API call / resource returns with a 401, alerting that the token has expired, this sometimes is accompanied by a reason, e.g. Expired token, invalid token
Create a reference to the API call that failed, to retry later
Attempt to refresh the token with the refresh_token
If the refresh works, go ahead and perform the queued API call again
If the refresh fails, the user will need to log in again
You can also use the above approach to queue multiple failed requests, in the event that multiple calls fails whilst a refresh is taking place.
Coupled with a decent expiry time, which really depends on your application, this has proven to be a robust solution in the past for me.
An alternative approach would be to implement a 'heartbeat' API call that updates the user's token periodically whilst they are on the site, however this may come with side effects that may not be desired.