https://developers.google.com/android/management/reference/rest/v1/enterprises.webTokens#resource:-webtoken
A web token used to access the managed Google Play iframe.
Is this web token will expire after some time or we can store the token and use it?
When we look at the response header of embedded iframe, we see the fields: "expires" (outdated) and "Cache-Control" (no-cache). This means that the response is considered out of date, it should only be used once.
The iframe will therefore be invalidated in the near future.
outdated iframe
cache-control field
A newly generated web token can be re-used for up to 4 hours after it was generated. Once the token expires, it cannot be used again and you should generate a new web token.
Related
Using CSRF token in rest API is helpful or not ? as far as I know we don't have a session so we should send the token to client for next request or for submitting the form.
Is it helpful to use it again in ajax(xhr) calls. are there any alternatives ?
I've been reading the spring documents for this, and it also has some examples. but I was curious that is it really helpful or not ?
By the way My server is spring 2.2 and my client is Angular 9.
Thanks
CSRF tokens are essential for preventing XSS attacks, for instance you are logged into your bank, in one tab, and visiting my malicious site that will send a hidden form to your bank stealing your credicard number.
If you want to build a more secure site, every request that manipulates the state in the backend (POST, PUT, DELETE etc) should have a CSRF token included, to ensure that the request came from forms on your site and only your site.
You can read more about CSRF tokens on Owasps webpage.
I have a dotnet core 2.2 MVC web application which uses a web api to perform some database queries. I have implemented JWT token based authetication for web api. Tokens are generated at the api and the web application has received the access token, expiry and refresh token. I need to store this token details at my client , so that I can either use it to access web api(before expiry) or generate new token using the refresh token if the token expires.
Any help on this would be appreciated.
You have various options (secure http-only cookie, localstorage, session storage, etc.).
In the most simple scenario, you can store it in a cookie so that it is sent along with each request :
The cookie should always have the HttpOnly flag to prevent XSS attacks in the browser.
The cookie should also use the Secure flag in production, to ensure that the cookie is only sent over HTTPS.
Protect your forms against CSRF attacks (by using ASP.NET Core’s AntiForgery features, for example).
Previous answers don't provide clear explanation about the reasons of using those solutions.
Typical systems look like on the picture below and there are two common Client Application architectures used in WEB:
Singe Page Application running in browser
Server side MVC application
In case of SPA the tokens are stored in browser (session storage or local storage) and are cleared automatically by either browser or the app itself when expire. FYI, obtaining refresh token is not possible in SPA because of security reasons.
In case of MVC app (your case) the things get more complicated. You have two options: either store it in http-only cookie or some external session store. Aspnet core supports both cases but each has caveats. A good article here. In short, if your are concerned about cookie size then use Distributed Session Storage which adds more complexity to the system architecture. Otherwise cookies is the easiest solution and is enabled by default in aspnet core, you just need to set options.StoreTokens = true and options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme.
There are multiple ways to store the tokens. Usually applications doesn't store access token anywhere, but they do store refresh token in a permanent storage.
Let's take a look at what you need to store at web and api end.
First, user will request to login in web application with credentials, web app will pass this request to the api project - which interacts with DB.
Now, api will generate access tokens and refresh token and the save refresh token to that DB. Web api then need to store access token and refresh token in temporary storage like cookie or session.
When access token is expired; you need to make a call for a new tokens, which will update the previous refresh token in the DB.
TL;DR
Refresh token - in DB
Access token and refresh token - web temporary storage
Make the call from ui to web application server(controller) controller which in turn makes call to get the token from api.
get the token from api response and store it in cookie.
you controller should look something like this
var option = new CookieOptions
{
Expires = DateTime.Now.AddMinutes(response.ExpiresIn)
};
if (!string.IsNullOrEmpty(domain))
{
option.Domain = domain;
}
Response.Cookies.Append({cookiename}, response.AccessToken, option);
I'm moderately familiar with OAuth2 and the concepts of the AccessToken and RefreshToken.
It looks like MSAL is doing some work for us when using ClientApplicationBase.AcquireTokenSilentAsync().
I'm not clear as to whether it will always check the expiration of the current AccessToken and automatically refresh it (using the RefreshToken) on method call.
Regardless, is there a "best practice" for how often we should call AcquireTokenSilentAsync() ? Should we keep track of the expiration ourselves and call this method to update our bearer authentication header? Should we be calling AcquireTokenSilentAsync() on every Request? (doubtful)
I can't see how the GraphServiceClient (tangent topic, I know) using the DelegateAuthenticationProvider will do anything helpful WRT refreshing. Do we need to extend that class and perform our own refresh when the token is nearing expiration? I feel like this would/should be already in the SDK.
Thanks for any tips.
-AJ
Update Nov 2020
This answer was originally written for V2 of the MSAL client. Since then a V3 has been released which may work differently from V2.
Original answer
I'm not clear as to whether it will always check the expiration of the current AccessToken and automatically refresh it (using the RefreshToken) on method call.
A refresh token is automatically supplied when the offline_access scope is provided, if I understand this answer correctly
...you've requested the offline_access scope so your app receives a Refresh Token.
The description of AcquireTokenSilentAsync implies that when an refresh token is provided, it will check the expiration date on the token, and get a new one if it's expired or close to expiring.
If access token is expired or close to expiration (within 5 minute
window), then refresh token (if available) is used to acquire a new
access token by making a network call.
It will repeat this behavior until the refresh token is expired. Optionally you can force a refresh of the access token via the refresh token by utilizing the forceRefresh parameter on AcquireTokenSilentAsync
Lastly, I am going to quote this answer on SO since it gives a nice insight about MSAL and tokens
Just to make a small clarification, MSAL doesn't actually issue tokens
or decide a token expiration, but rather ingests an acquires token
from the Azure AD STS.
MSAL will automatically refresh your access token after expiration
when calling AcquireTokenSilentAsync. .... The default token
expirations right now are:
Access Tokens: 1 hour
Refresh Tokens: 90 days, 14 day inactive sliding window
(June 13th '17)
Regardless, is there a "best practice" for how often we should call
AcquireTokenSilentAsync() ? Should we keep track of the expiration
ourselves and call this method to update our bearer authentication
header? Should we be calling AcquireTokenSilentAsync() on every
Request?
The documentation also lists a 'Recommended call pattern' for calling the AcquireTokenSilentAsync. The documentation also mentions that
For both Public client and confidential client applications, MSAL.NET maintains a token cache (or two caches in the case of confidential client applications), and applications should try to get a token from the cache first before any other means.
Based on examples I've seen, including the recommended call pattern from the documentation, I would argue you could simply call AcquireTokenSilentAsyncand catch the MsalUiRequiredException as an indication that the token has expired and the user has to log in again.
I can't see how the GraphServiceClient (tangent topic, I know) using the DelegateAuthenticationProvider will do anything helpful WRT refreshing. Do we need to extend that class and perform our own refresh when the token is nearing expiration? I feel like this would/should be already in the SDK.
If I understand the DelegateAuthenticationProvider correctly, what it does is modify the requestMessage before we pass it to Graph. All we got to do is provide our access token with an authorization header for the request. We already know that when we fetch our access token, it is valid, so we can just add it.
new DelegateAuthenticationProvider(async (requestMessage) =>
{
ConfidentialClientApplication cca = new ConfidentialClientApplication(_ClientId, _Authority, _RedirectUri, new ClientCredential(_ClientSecret), _UserTokenSessionCache.GetTokenCache(identifier, httpContext), _ApplicationTokenCache.GetTokenCache());
AuthenticationResult result = await cca.AcquireTokenSilentAsync();
requestMessage.Headers.Add("Authorization", result.CreateAuthorizationHeader());
//OR
requestMessage.Headers.Authorization = new AuthenticationHeaderValue("bearer", result.AccessToken);
});
(There is no difference between either way of setting the headers)
I've been down this path and this does the trick for me. I highly advise reading their documentation, because it does gives a good insight in how to implement MSAL.Net.
I haven't had time yet to play around with the token durations yet. Nor the behavior if no refresh token is provided (if that's even possible)
I hope this helps!
Mentioning one thing missed above, quoting my answer to Get refresh token with Azure AD V2.0 (MSAL) and Asp .Net Core 2.0
For context, OAuth 2.0 code grant flow mentions the following steps:
authorization, which returns auth_code
using auth_code, to fetch access_token (usually valid for 1 hr) and refresh_token
access_token is used to gain access to relevant resources
after access_token expires, refresh_token is used to get new access_token
MSAL.NET abstracts this concept of refresh_token via TokenCache.
There is an option to serialize TokenCache. See Token cache serialization in MSAL.NET. This is how to preserve sign-in info b/w desktop application sessions, and avoid those sign-in windows.
AcquireTokenSilentAsync is the process by which refresh_token is used to get new access_token, but, this is internally done. See AcquireTokenSilentAsync using a cached token for more details and other access patterns.
Hope this clarifies on why TokenCache is the 'new' refresh_token in MSAL.NET, and TokenCache is what you would need to serialize and save. There are libraries like Microsoft.Identity.Client.Extensions.Msal that aid in this.
#AlWeber/ #Raziel, the following pattern would apply for PublicClientApplication:
on startup, to deserialization and load TokenCache (which has refresh_token), try acquire access_token silently.
if that fails, use interactive UI to fetch token.
save and re-use the AuthenticationResult, which has AccessToken and ExpiresOn. Redo acquire access_token silently (bit expensive if you are an API user, hence caching of result), once you are close to ExpiresOn property (personally, I set 30 min before expiry).
is there a "best practice" for how often we should call AcquireTokenSilentAsync() ? Should we keep track of the expiration ourselves and call this method to update our bearer authentication header? Should we be calling AcquireTokenSilentAsync() on every Request? (doubtful)
I don't think this is a good idea. As mentioned, this call is still a bit expensive. Alternative, is to store AuthenticationResult in-memory, re-use it, and go to silent acquire workflow only close to ExpiresOn property.
I'm developing an angularjs web app.
To access server side api, I need to add an id_token header and
I receive an id_token, by using https://accounts.google.com/o/oauth2/auth endpoint.
The crux of the matter is this - the id_token has an expiration date. Before accessing server API, I need to make sure the id_token is not expired yet, but if it is, the obvious choice would be to refresh it.
Is there any way I can refresh the id_token?
I know I could change access_type to offline, and receive a refresh_token, but it does seem pretty weird to ask for an offline access, when basically in my case user interacts with the server only at the moment when he actually using the web app online.
Forget all about refresh tokens and offline access. This method is only applicable for server and desktop apps. To have a refresh token present in the browser would be a massive security hole.
If you read the docs for the Google JS OAuth library, you'll see that it's easy to get a new access token once the current one expires. See gapi.auth.authorize() and note the comment for immediate=true. NB this method is deprecated, although it works. Absolutely everything you need to is at https://developers.google.com/api-client-library/javascript/reference/referencedocs
When the id_token expires, the client requests new tokens from the
server, so that the user does not need to authorise again.
From IMPLEMENTING A SILENT TOKEN RENEW IN ANGULAR FOR THE OPENID CONNECT IMPLICIT FLOW
I can see OAuth working well for a fully Ajaxified application, as the local JS code can always replay the Bearer token to the server. However, what happens if we have a page refresh? In that case I assume we lose the token and then go back through the OAuth redirect process to get yet a new access token issued. Is this correct, and are there patterns to avoid this, such as storing the access token in HTML5 local storage?
If you're talking OAuth 2.0 then you can probably request both a refresh token and access (or Bearer) token when you authenticate with the OAuth 2.0 provider. The refresh token should be returned directly to the server hosting the web application, stored somehow (perhaps session state) and NOT ever exposed to the browser. The browser can use the access token to make requests to secured services/endpoints which require it but it should have a short lifetime (regardless of whether or not there was a page refresh). When it expires (again may or may not be due to a page refresh) the client application can make a request to the hosting server where the refresh token was delivered. The server can then use the refresh token to get a new access token WITHOUT the user needing to login again.
There's a diagram of this in the refresh token section of the OAuth 2.0 spec.
There are several variations of how OAuth 2.0 can be used and details may vary with your particular scenario and implementation but hopefully that gives you a high-level idea of how you can avoid prompting the user to re-authenticate when the access token expires or on page reload.