I have been using Force.com Toolkit for .NET for long time. Recently one of a client has started complaining for session invalid issue. So I started digging up and found that I have to refresh token by calling TokenRefreshAsync for which I need to pass on refresh token which I get during authentication. But I am getting null refresh token from SF.
I have tried everything possible thing I found on the internet without any success. Perform requests on your behalf at any time (refresh_token, offline_access) is added in OAuth Scopes:
Refresh token expiry is set at 2 days:
This is the simple code I am using to authenticate:
var task = authClient.UsernamePasswordAsync(consumerKey, consumerSecret, username, password, callback);
task.Wait();
What am I missing here?
The Username-Password Oauth Flow does not provide a refresh token on Salesforce, regardless of scopes:
This OAuth authentication flow passes the user’s credentials back and forth. Use this authentication flow only when necessary. No refresh token is issued.
If you want a refresh token, you'll need to implement a different OAuth flow (preferable!), or eschew the refresh token and reauthenticate when your access token expires. The latter makes you vulnerable to credential and security token changes on the part of the authenticated user, however, which using a more suitable OAuth flow grants resilience against.
Related
When the token is generated by sending a HTTP request to web API & the user has started working on the application that generated token is used in a particular session of the application. If during any HTTP request from the application to web API if JWT token expires WEB API won't return data. How is this situation handled in the application without any misbehavior or without troubling the user how that request will be continued?
And even if we generate a refresh token how to continue with the same HTTP request without troubling the user?
(If we store the generated token in the database then we know the token is valid but expired)
Try this :
Write backend refresh token API and allow an authenticated user to refresh their JWT token
In Frontend before requesting the API call decode the user's current JWT token and check whether it is expired or not.
https://www.npmjs.com/package/jwt-decode
If the token expired call the refresh token API before the actual request.
If you are using Angular or React library then there is a mechanism called HTTP_interceptor
https://www.bezkoder.com/angular-12-refresh-token/
https://www.bezkoder.com/react-refresh-token/
We also give a refresh token to the user along with the token, which has no claim and only has a username and a long expiration date. Every time the token expires, the security part of the applicationlooks at the refresh token and issues a new token for that username. You can manage the issuance of program tokens by setting the refresh token lifetime
I’m writing a web api that will be called from a background service to fetch some data. After some research I decided to use a Json web token to achieve that but I’m still a bit confused regarding when a new token should be requested.
Let’s say I start up my service, I request a token, the token expires after 15 minutes, then after 20 minutes I make an api call with the expired token. I will get an unauthorized error or something.
My question is: How will the client know when to request a new token? Should it request a new one before every api call? Seems like I’m missing something. Maybe I should make the token permanent and store it in the database?
Thanks
The answer to this is slightly application specific, but the OAuth specification has a mechanism for "refresh tokens", which can be used to grant new "access tokens" (the token typically included on each API request), without having to send the user to the UI authentication process to have them re-authenticate. So, once you request an access token, you will receive a refresh token and an access token. This methodology allows access tokens to be used for much shorter time frames.
This can also be done without refresh tokens, but in those cases the access token timeout would likely be longer, and then you would request that the user re-authenticate through the usual OAuth UI process. Note that even when you do have refresh tokens, the refresh token can also be set to expire, in which would then require a user re-authentication through UI again.
In some API's you just make the API request as usual, and if you get a response that is defined by the API to be one that indicates the access token has expired, you can then issue an API call to refresh the token (or fully request a new one if that is expired, or you the API doesn't have refresh tokens), and then make the original API call again with the new access token.
The API can also have a response that includes the timeout or expiration date/time of the access token as well. Then, the client can avoid sending the initial API call first, and simply send the refresh token call first.
In implementing your API, you could likely use any of these methodologies.
Here's some general discussion on the OAuth spec website, to provide more depth:
https://www.oauth.com/oauth2-servers/making-authenticated-requests/
https://www.oauth.com/oauth2-servers/access-tokens/access-token-lifetime/
https://www.oauth.com/oauth2-servers/access-tokens/refreshing-access-tokens/
And also, here's an example from the Twitter API regarding response codes showing one of the access token expiration techniques (see the "Error Codes" section, under error code 89, which implies the token has expired and you need to get a new one):
https://developer.twitter.com/en/docs/basics/response-codes
Since your client is background service , you can use the Oauth2 Client Credential Flow . Your background service can request an access token using only its client credentials when the client is requesting access to the protected resources under its control.
With this flow , you does't need to care much about the token expires , if client sends an expired token to web api , web api validate the token and create token expires response to your service , your service check the status code/response , directly send a new token request to web api to get new access token , there is no need to use refresh token which uses in other flows .
The fact is that your harness should be prepared to request any token when getting an Unauthorized status code. What I do in test is to check the expiration datetime, if close enough I refresh or get a new token whatever applies to your Auth. Also when getting an unauthorized status code my code does a refresh once and keep a count. If I get another unauthorized code then I return a false or throw an exception after I log the error on the second try. This works fine for me.
The Office365API provides a nice way to get an access token but there are no example on how to handle the situation when the token expires. Moreover, there does not seem to be a refresh token.
On the blog "How to: Integrate Office 365 with a web server app using Common Consent Framework"
[ http://msdn.microsoft.com/en-us/library/office/dn605894(v=office.15).aspx ] there is the notion of getting a refresh token along with the access token. When the access token expires the refresh token can be used to get another access token / refresh token set without requiring the user to log into their office 365 account again.
Does anyone know how to handle the expired access token using the Office365APIs?
The way i do it is
await _outAuthenticationInfo.ReauthenticateAsync(ExchangeResourceId);
I want to post an update to my own facebook page from a .NET service. I can make a FB App and that wants 'publish-actions' and 'manage_pages'. But how can I get an accessToken in code. The posts would be infrequent so I don't mind generating a new access token each time, but I need it done by the service without any interaction from me.
Following scenario 5 of https://developers.facebook.com/roadmap/offline-access-removal/ should allow you to authorize once as a user and then use the page token indefinitely without any need to re-authorize.
Exchange the short-lived user access token for a long-lived access token using the endpoint and steps explained earlier. By using a long-lived user access token, querying the [User ID]/accounts endpoint will now provide page access tokens that do not expire for pages that a user manages. This will also apply when querying with a non-expiring user access token obtained through the deprecated offline_access permission.
https://developers.facebook.com/roadmap/offline-access-removal/
I'm using dotNetOpenAuth to authorise against Google oAuth provider.
I'm a bit confused with the difference between the following:
consumerToken, consumerSecret, accessToken
From the Provider I get the accessToken for some user. Can keep I it forever? Or does it expires?
How can the code enable authorization without redirecting the user to the "allow access to my google data page" ?
Never expect have any expectations about lifespan of accessToken. At any time you can be given 403 HTTP error which should trigger on of the following in your app:
If you have a refreshToken, get a new accessToken without resource owner (end user) interaction
If not, ask user again to authorize your application
OAuth 1.0, which you're using, does not include a provision for predicting when an access token will expire, so you'll have to read Google's documentation for OAuth 1.0 access tokens to see how long they last.
How can the code enable authorization without redirecting the user to the "allow access to my google data page" ?
You don't. If you could do that, that would be a huge security leak. The user must authorize your app to access his/her data. Once you've obtained authorization once however, by storing the access token (and its secret) that you obtained you should be able to use it in the future and avoid the user authorization step (until the user revokes the token or it otherwise expires).
"AccessToken" in OAuth normally have relatively short expiration (i.e. in Facebook and Messenger case less than a day). If implementation supports it then "refreshToken" is the one you can keep longer (weeks/months range depending on provider).
According to the doc ( https://developers.google.com/accounts/docs/OAuth2 ) Google supports refresh tokens, so if you want to store token - it is the one.
Note that both accessToken and refreshToken represent very sensitive information (comparable to clear text user name and password), so please check out provider's recommendations and requirements on storing these information.