When pulling information from the LinkedIn API, the access token will randomly expired, and the application will not be able to pull the information from the API. This issue randomly occurs after an extended period of time. I am trying to determine whether this could possibly be coming from LinkedIn's side. Is there any way to verify?
According to the LinkedIn documentation, you should receive the expiration date of the access token in the same request you receive the token.
Access Token Response
A successful Access Token request will return a JSON object containing
the following fields:
access_token — The access token for the user. This value must be kept secure, as per your agreement to the API Terms of Use.
expires_in — The number of seconds remaining, from the time it was requested, before the token will expire. Currently, all access tokens are issued with a 60 day lifespan.
One thing to keep in mind is that access tokens can be manually revoked by the user:
Invalid Tokens
If you make an API call using an invalid token, you will receive a
"401 Unauthorized" response back from the server. A token could be
invalid and in need of regeneration because:
It has expired.
The user has revoked the permission they initially granted to your application.
You have changed the member permissions (scope) your application is requesting.
Since a predictable expiry time is not the only contributing factor to token invalidation, it is very important that you code your applications to properly handle an encounter with a 401 error by redirecting the user back to the start of the authorization workflow.
One thing that is not mentioned on this page, as #JustinKominar mentioned, is that only your most recent access token is valid. That means requesting a new access token will invalidate all of the previous ones, so make sure that your tokens are up to date!
Related
I'm using directus to grant users access to ressources required by an SPA written in Angular. To authenticate users I created an auth service and interceptor to handle sessions and attach the "Authorization" header. Those services work fine and login as intended. But here comes the problem:
Directus session times are configured with default values (15 min validity for access_token, 7d for refresh_token) but as soon as the access_token expires I cannot retrieve a new one using the refresh token. This bugs me, because the goal is to keep users logged in for the next 7d (refresh_token lifespan) or until logout if they check this option.
My attempts at achieving this:
Since i'm using graphQL, i tried the "auth_refresh" mutation from the authentication documentation. While the access token is still valid, refreshing works fine. After the access token expired there is no way to retrieve a new one via a valid refresh token.
Alternatively I tried to achieve a refresh via the POST request specified by the docs (to double check if it was some sort of config error with graphql) but I encounter exactly the same problems as with graphQL. Directus returns either "401 unauthorized : Token expired."
if i extend the lifespan of the access token for longer than the server defined lifetime,
Response: Sending a token with prolonged life
or "401 unauthorized : Invalid user credentials." if I request a new token without an
"Authorization" header.
Response: Sending no access token
The refresh token is correctly loaded and sent to the server as specified in the docs in both
cases.
Now my questions are:
Am I missing something? I haven't found any further specification in the docs and the Auth0 protocol specifies that a new access token should be retrievable with a valid refresh token.
If this feature is not intended: How could I achieve a "keep me signed in" option with directus? I would like to keep user rights management in one place and do not really want to handle user auth redundantly for my current use case.
2b. Why is the lifespan of the refresh token so much longer than the lifespan of the access token if this isn't intended?
One of my thoughts is, that it has to do with access rights of the "public" role on the "directus_sessions" table. But I can't think of a way to grant only read rights for owned/received tokens, since there are no payload variables available inside the filters. Could this be the cause? Would there be a way to achieve this?
Thx&Greetz
I am integration Salesforce OAuth in my application. After mapping users' Salesforce account with our application account I saved access token in DB. When user make request to fetch data from his Salesforce account I just use that token to get data. Sadly, token has expiration time (max 24 hrs). After token is expired user has to again connect salesforce account with our app.
Is there anyway to keep salesforce session alive for unlimited time or any other way to avoid repeated login?
I think what you are looking for is a Refresh Token process. Although you can control the expiration time, as you said there is certain limits you can't pass. Instead you can send a request to your org that can obtain new Session ID for you.
Example:
POST /services/oauth2/token HTTP/1.1
Host: https://login.salesforce.com/
grant_type=refresh_token&client_id=3MVG9lKcPoNINVBIPJjdw1J9LLM82HnFVVX19KY1uA5mu0
QqEWhqKpoW3svG3XHrXDiCQjK1mdgAvhCscA9GE&client_secret=1955279925675241571
&refresh_token=***your token here***
Note that this does not work if you are using username-password OAuth authentication flow. Check this dev documentation for the parameters you can use for Refresh Tokens and what responses can it return. - https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_understanding_refresh_token_oauth.htm
It is not possible to make sure that user session never expires. However, you can setup the session timeout value to a maximum of 24 hours.
I agree with Iojo. I implemented the similar requirement to save the Token in DB and reused it for multiple API callouts.
Note: In my case - for all the API callouts - Authentication layer are taken care by same middleware. Additionally, I am using username-password for access token where, clearly, I cannot use refresh token.
What I did for Access Token with token
saved in DB?
//Please create a re-usable method in the Rest handler to Retrieve Token
private string getToken(){
If(Token created within Session Timeout Limit){
//Use encrypted token given in the DB
}
else{
//reuse code to generate new token
//save the encrypted token in the DB for future use
}
}
Benefits:
You need to generate Token just one time within given Session Timeout Limit
Re-use the same if there are multiple API calls in salesforce
My requirements
I have a Web API which gives me required data from the database. I have a .Net website which consumes this Web API to get all data. Now the requirement is to protect the APIs from being exposed to anyone on the web.
What I have done so far:
On the website:
I generate a token when the user logs in. This token holds the details like username, a random key and the expiration time of the token, all in an encrypted string.
On the API:
Upon every request, before sending the response, I decrypt the token and validate if the username, key and expiration time are valid. If all of them are valid, the response will be sent. Otherwise, an error message is sent in response.
This is the function that I made changes in:
protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
{
AuthenticationHeaderValue authorization = request.Headers.Authorization;
if (authorization != null)
{
if (Encryption.DecryptData(token).Equals(ConfigurationManager.AppSettings["TokenKey"].ToString()))
{
//Send response
}
}
}
Everything is good till here.
Now the problem is...
Let us say that I put an expiration time of 15 minutes for the token. The generated token hence can be used for 15 minutes after login to get responses from the API.
This token can be used irrespective of the user's login status i.e, the token is valid for 15 minutes even if the user signs out immediately after logging in.
I have been brainstorming and searching for solutions for the past few days and I came across the thought of handling the data in sessions but found later that it is a bad idea with respect to scalability.
There are also constraints that I cannot use OWIN. Additionally, the project is not MVC, it is a Web API project.
Can someone please come to my rescue and point me towards a solution? I'll be grateful as this has already consumed a lot of time.
You can't invalidate token.
If user have token, than He is logged in.
I had this problem, when i had to invalidate tokens, and any workaround i found dosn't work in your situation.
how-to-force-invalid-bearer-token-in-web-api
If user has valid token, then he is as good as loged in. When he log out, you can only clear he's cookie with token. It's not a bug, it's a feature ;)
Best solution is to accept this and don't worry about what user want to do with his token.
You might be storing the token details somewhere (an SQL database maybe) in order to validate it in the API. Why not add a bit field "Enabled" in the database which is set to 0 when the user logs out then have the API check that field as part of the validation as well as checking the user, token and expiry time.
Maybe a simple question.
Lets say that the user receives the bearer token and has an expire time of 1 day.
the user makes calls to the web api and then stops making calls say after 6 hours.
Then if the user makes a call to the web api does that auto refresh the token and then the user has another 24 hours to use the token or will it definatly expire based on the first get of the token.
thanks
Once issued, the token cannot be changed and will be valid until it expires. It doesn't matter how or when the token was used or even if other tokens were requested in the meantime.
Since the token cannot be changed, the expiration of the token cannot be extended. The token can however be revoked before it expires, based on other factors, if the server is configured to do so.
It may not be possible to extend the token itself, but it is possible to request a new token without having to send the credentials.
You can configure the server to add a refresh token to the token. Please note that this is not available for all grant_types. In case of a refresh token the normal token has an extra parameter 'refresh_token' that contains an additional token with its own expiration time. This token can be used once the normal token is expired. In that case a new token can be requested with this refresh token, without having to send the credentials.
In Webserver Grant Flow
After I obtain the Authorization Code from the authorization authority (after the user has authorized my access) how long is that code usually valid form?
The reason i am asking is, can my webserver store that code and use it in later sessions to retrieve a new access token without the need for the user to re-authenticate again? Should that be the flow?
FYI my goal is make requests from Adobe Analytics and Google Analytics on behalf of my customer. So i would want to ask my customer for authorization once until he revokes my access.
Speaking strictly of Google Oauth. There are three types of codes or tokens you should be aware of.
Authorization code
Access token
Refresh token
Authorization code is return when the user clicks accept to your application accessing their data. This code is used to exchange for an access token and a refresh token. This code can only be used once and is extremely short lived 10 minutes I believe.
Access tokens are used to access private user data. They are valid for approximately one hour.
Refresh tokens are used to gain a new access token when the access token has expired. For the most part refresh tokens do not expire however if it has not been used for six months it will no longer be valid and of course the user can always remove your access.
Answer: No storing the authentication code would be pointless. You will need to store the refresh token. make sure you are requesting offline access of your users.
I cant help you with adobe analytics however I suspect it is similar this is standard Oauth protocol we are talking about.