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
Related
I like to implement the functionality
where if two users are trying to login with the same credentials then the first user should log out as soon as the second user login.
consider user one is logged in with his credentials from one machine
and he/ another user is trying to log in from another machine
then the user one session should be removed as soon as user one logged in.
Ps:
I tried to implement that by saving the current session id in the user table and overriding the OnCreated method from the IAuthSession interface and then checking in that if the request sessionId is the same as the saved session Id if same then process the request else call the lout endpoint.
But It will be not good for performance and I am not sure if it is a good way to do that?
PS: I am using a JWT token.
Update :
I am able to clear the session by using ICacheClient to get the session and then remove a session from the server using IRequest.RemoveSession(sessionId), but is it not log out the specific user.
You can't invalidate a user authenticating with stateless authentication like JWT which has the signed authentication embedded in the Token which is valid until the JWT expiry.
i.e. you can't revoke a JWT Token after it's already been issued.
There is a JwtAuthProvider.ValidateToken filter you can use to execute custom logic to prevent a user from authenticating which you may be able to use however that would require that you manage a collection of Token info you want to prevent from authenticating before its Token expiry.
I am able to allow users to log in to Firebase using email and password. I followed these instructions: https://firebase.google.com/docs/reference/rest/auth/#section-sign-in-email-password
However, after 1 hr it seems the auth expires and I can't use my app anymore. Does anybody know how I can extend that hour? I have read MULTIPLE posts with very similar questions, but I can't find a clear answer. IT seems some people think there is a way to obtain a reauth token or something like that, but still no clear answer.
Manage User Sessions
Firebase Authentication sessions are long lived. Every time a user signs in, the user credentials are sent to the Firebase Authentication backend and exchanged for a Firebase ID token (a JWT) and refresh token. Firebase ID tokens are short lived and last for an hour; the refresh token can be used to retrieve new ID tokens. Refresh tokens expire only when one of the following occurs:
The user is deleted
The user is disabled
A major account change is detected for the user. This includes events like password or email address updates.
Manage Tokens on Web Client
The website client code can call User.getIdToken(forceRefresh?: boolean):
Returns the current token if it has not expired. Otherwise, this will refresh the token and return a new one.
This would need to be called each time a token is sent to the server.
Alternatively, user sessions may be managed via session cookies.
Manage Session Cookies
Firebase Auth provides server-side session cookie management for traditional websites that rely on session cookies. This solution has several advantages over client-side short-lived ID tokens, which may require a redirect mechanism each time to update the session cookie on expiration:
Improved security via JWT-based session tokens that can only be generated using authorized service accounts.
Stateless session cookies that come with all the benefit of using JWTs for authentication. The session cookie has the same claims (including custom claims) as the ID token, making the same permissions checks enforceable on the session cookies.
Ability to create session cookies with custom expiration times ranging from 5 minutes to 2 weeks.
Flexibility to enforce cookie policies based on application requirements: domain, path, secure, httpOnly, etc.
Ability to revoke session cookies when token theft is suspected using the existing refresh token revocation API.
Ability to detect session revocation on major account changes.
Okay so in my iOS app I log the user into firebase, then get the jwt token. So now I have my server with an api which accepts an idtoken in the header of the GET.
What do I do here? Certainly I wouldn't be validating the JWT againt firebase on every single API call right? I mean its fast, but that adds latency with a second external check, no? How does one simply just decode that guy in C#? I have an Auth0 layer already and that decodes the JWT with my server-stored secret, but that same code doesn't work for the Firebase token.
Could it just be decoded then extract the user details from that, maybe just check expiry and if expiry > X months it's still okay?
In order to verify Firebase ID tokens and JWTs in general, you only make a network call on your server to get the public certs which are usually not updated for several hours. You could cache that and try to verify with an ID token and if it fails, only then, load the new public certs.
And yes, you must verify the ID token on each call especially since Firebase ID tokens expire after typically an hour and need to be refreshed continuously.
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.