Description
In Web Api project template, after sending a POST request to the Token endpoint: www.mycoolwebsite.com/Token, we get a Json similar to this:
{
"access_token":"qkRwQD0A85...",
"token_type":"bearer",
"expires_in":14,
"userName":"admin#mycoolwebsite.com",
".issued":"Wed, 24 Feb 2016 18:15:53 GMT",
".expires":"Wed, 24 Feb 2016 18:16:08 GMT"
}
On the client side, (let say a mobile application) I am saving this json on a file, and to see if the token is expired, I compare DateTime.UtcNow to token's .expires key.
Question
Is this the correct way to see if an access token has expired?
If not, what is the best way check this?
I wouldn't check the access token's expiry time. Rather than build a mechanism to check the expiration time and handle it, why not just send the access token you have to the API and, if you get a 401 back, request a new access token. You'll have to build in logic to handle 401's anyway...why not rely on that instead?
Related
I'm getting this response (with 401 error code) after using the new refreshed access token:
{'serviceErrorCode': 65601, 'code': 'REVOKED_ACCESS_TOKEN', 'message': 'The token used in the request has been revoked by the user'}
I followed this guide to refresh the access token:
https://learn.microsoft.com/en-us/linkedin/shared/authentication/programmatic-refresh-tokens?view=li-lms-2022-07#step-2-exchanging-a-refresh-token-for-a-new-access-token
Although it works after several seconds. It seems like the issue is from the LinkedIn-Ads API side. Is there an exact time to wait after generating the access token?
I am using ASP.NET Boilerplate framework, I put the below code in everypage.
#inject IAbpAntiForgeryManager AbpAntiForgeryManager
#{
AbpAntiForgeryManager.SetCookie(Context);
}
I call the app service as below:
var xhr = abp.services.app.order.add(data);
xhr.done(function (data) {
alert(data);
});
Everything works fine when I run in localhost, XSRF token will not expired even if I rebuild the project. Every time when I click [Publish website to IIS], all the ajax request will return 400 Bad Request, I guess it is because the XSRF token has expired, everything back to normal after I click F5 in browser. It was so annoying for the user, any thing I can do to prevent this error? Or auto refresh token?
Thank you!
update
error message in LOG file:
ERROR 2019-02-12 13:40:09,773 [71 ] .Antiforgery.Internal.DefaultAntiforgery - An exception was thrown while deserializing the token.
Microsoft.AspNetCore.Antiforgery.AntiforgeryValidationException: The antiforgery token could not be decrypted. ---> System.Security.Cryptography.CryptographicException: The key {996d31d2-0fa3-4ffe-8e82-e155c1486d33} was not found in the key ring.
Based on the error it sounds like your Data Protection keys have rotated on publish.
Check out the docs on Data Protection here: https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/introduction?view=aspnetcore-2.2.
There's a bunch of options how to configure it, where to store keys etc.
You'll want to change how it is storing them.
More on configuring Data Protection: https://learn.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview?view=aspnetcore-2.2.
I'm using Firebase Auth to have users authenticate using their Google Account. I found the token returned by firebase.auth().currentUser.getIdToken is only valid for 1 hour. To allow the session to last longer I tried creating a session cookie as outlined in Manage Session Cookies:
const expiresIn = 60 * 60 * 24 * 5 * 1000;
admin.auth().createSessionCookie(idToken, {expiresIn}).then((sessionCookie) => {
const options = {maxAge: expiresIn, httpOnly: true, secure: true};
res.cookie('session', sessionCookie, options);
res.end(JSON.stringify({status: 'success'});
}
This code successfully created a session cookie and subsequent requests could be verified using admin.auth().verifySessionCookie. All was well until I tried increasing the expiresIn duration. It turns out that Firebase session cookies have a maximum expiration time of 2 weeks. From the docs:
Ability to create session cookies with custom expiration times ranging from 5 minutes to 2 weeks.
For this project I would prefer to have a user log in once and stay logged in. I tried extending the session on every interaction with the server but I didn't find any official documentation on how to do that. It seemed to make sense to call admin.auth().createSessionCookie on the server using the token returned by admin.auth().verifySessionCookie, but that failed with this error:
Failed to extend session: { Error: An internal error has occurred. Raw server response: "{"error":{"code":400,"message":"Invalid value at 'valid_duration' (TYPE_INT64), 604.8","errors":[{"message":"Invalid value at 'valid_duration' (TYPE_INT64), 604.8","domain":"global","reason":"badRequest"}],"status":"INVALID_ARGUMENT"}}"`enter code here`
at FirebaseAuthError.Error (native)
at FirebaseAuthError.FirebaseError [as constructor] (/user_code/node_modules/firebase-admin/lib/utils/error.js:39:28)
at FirebaseAuthError.PrefixedFirebaseError [as constructor] (/user_code/node_modules/firebase-admin/lib/utils/error.js:85:28)
at new FirebaseAuthError (/user_code/node_modules/firebase-admin/lib/utils/error.js:143:16)
at Function.FirebaseAuthError.fromServerError (/user_code/node_modules/firebase-admin/lib/utils/error.js:173:16)
at /user_code/node_modules/firebase-admin/lib/auth/auth-api-request.js:726:49
at process._tickDomainCallback (internal/process/next_tick.js:135:7)
errorInfo:
{ code: 'auth/internal-error',
message: 'An internal error has occurred. Raw server response: "{"error":{"code":400,"message":"Invalid value at \'valid_duration\' (TYPE_INT64), 604.8","errors":[{"message":"Invalid value at \'valid_duration\' (TYPE_INT64), 604.8","domain":"global","reason":"badRequest"}],"status":"INVALID_ARGUMENT"}}"' },
codePrefix: 'auth' }
Is it possible to extend Firebase sessions on the server side without requiring the client to do any work? Is it possible to use Firebase auth with tokens with a longer lifespan than 2 weeks? If not, in there a standard approach on how to achieve incredibly long lived sessions?
Extending it too long can be risky, as if the cookie is leaked, the window of attack will be quite wide. I don't recommend extending the session longer but if this is a requirement, you could try to do the following:
after verifying the session cookie on your server for the user and noticing it is about to expire.
mint a custom token for that user ID with Admin SDK
signInWithCustomToken with that custom token.
user.getIdToken() to get new ID token.
Exchange that ID token for a new session cookie.
The downside is that the claims in the session cookie will correspond to a custom token user.
Notice for client side sessions, the ID token passed around has one hour duration, even though the session is indefinite. This is because a refresh token lives on the device and is used to exchange new ID tokens. At any time, only the ID token is transmitted limiting the window of attack to one hour if that token is leaked.
I think it would be useful for Firebase Auth to offer an active duration functionality. That would be better for extending sessions continuously in short increments. This would be better than minting an indefinite or very long cookie. An active user would constantly have their session extended. This is not offered by Firebase Auth but you can file a feature request for it.
Any ideas why this is. I have configured a Server Application and a Web API and an ID Token, Access Token & Refresh token is issued. However calling the userinfo endpoint return a 401 with the following header message:
WWW-Authenticate →Bearer error="invalid_token", error_description="MSIS9920: Received invalid UserInfo request. The access token in request is not valid."
The access token is valid according to http://jwt.io
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IjVVbEw5a1JocDJNLUVzTDlBRDJOQ055aHZtdyJ9.eyJhdWQiOiJ1cm46bWljcm9zb2Z0OnVzZXJpbmZvIiwiaXNzIjoiaHR0cDovL3Rlc3Rsb2dpbi51bm9wcy5vcmcvYWRmcy9zZXJ2aWNlcy90cnVzdCIsImlhdCI6MTQ4NjYyOTUxOSwiZXhwIjoxNDg2NjMzMTE5LCJhcHB0eXBlIjoiQ29uZmlkZW50aWFsIiwiYXBwaWQiOiJrbnVkIiwiYXV0aG1ldGhvZCI6InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDphYzpjbGFzc2VzOlBhc3N3b3JkUHJvdGVjdGVkVHJhbnNwb3J0IiwiYXV0aF90aW1lIjoiMjAxNy0wMi0wOVQwODozMjo1Ny4xNDZaIiwidmVyIjoiMS4wIiwic2NwIjoib3BlbmlkIiwic3ViIjoiM2krUGlyRncwSVlkdDVzTVNKQlpKbjVOTXZVWXZVdyt2WHI2Ujd1N0dBZz0ifQ.ajKtSk0xQE1crJkIA-lMLBZj2DtYE6xQo-Stmevh4pOGX17GEePbAFP-g6qPUwtGT_whVj74wRpSlyTBscp2JDsp_CW2E6BsTUI810S6jYRVjkYGxL1QcL1KoKJ8wyYKcxsCeOY2IUKNPnJOxV53Rs8E9EvJgjcsjTJHQw5Z_zC43dsTfCZvVfGrwJ3nn6BGxhIE_bEXvrWdgmg49V7-KK2kVDbDwJGr1iLpqU88-bkHdjGCIuc8XKX5pobWWlcyBmR_dpACM6Tu-d8jYJ_8mbof-eZrqn8YS61rgvRAhAAONyDklWcPgiYnhcMQVHZoCME-rVTjI6LDDY2czhL0rg
This question is asked long time ago but let me share my experience.
if you want to execute ADFS 4.0 userInfo endpoint(win server 2016) in a hope to get User profile but what i experienced is it return only Sub attribute
ex:
{
"sub": "MpR57wSIQz1kiR2uUMrkCQadbgDoztWmMV863Dugdso="
}
for anyone to try UserInfo endpoint you need to modify your application group, add api with Identitfier https://adfs.example.com/adfs/userinfo & at Client permission tab tick openId.
for execution of userinfo
Ex:
curl -X GET \
https://adfs.example.com/adfs/userinfo \
-H 'Authorization: Bearer ACCESS_TOKEN
Note: In your Acquire Accesstoken code you need to pass your resource = urn:microsoft:userinfo
The ADFS userinfo endpoint always returns the subject claim as
specified in the OpenID standards. AD FS does not provide additional
claims requested via the UserInfo endpoint. If you need additional
claims in ID token, refer to Custom ID Tokens in AD FS.
I've only done this once so I don't have much suggestions to make yet. So I cant make any suggested unless there is more detail.
You should try and get more evidence from the AD FS side. Enable debug logs using
wevtutil sl "ad fs tracing/debug" /l:5 /e:true
Do the repro and then disable logs as follows.
wevtutil sl "ad fs tracing/debug" /e:false
Then export the logs to view using
wevtutil epl "ad fs tracing/debug" c:\temp\userinfoerr.evtx
Open that event log in event viewer and have look and see what other errors are reported around validating the JWT.
Has anything changed with regard to refreshing Google tokens using the MobileServiceClient against App Service. I used to be able to refresh Google tokens in my Xamarin Forms app using the MobileServiceClient. Now, after logging in, any attempt to refresh returns forbidden.
My login code is as follows:
public class Authentication : IAuthentication
{
public async Task<MobileServiceUser> LoginAsync(MobileServiceClient mobileClient, MobileServiceAuthenticationProvider provider)
{
return await mobileClient.LoginAsync(
Forms.Context,
provider,
new Dictionary<string, string>()
{
{ "access_type", "offline" }
});
}
}
My refresh code is:
var user = await MobileService.RefreshUserAsync();
The refresh fails even if I try refreshing immediately after my successful login. The Token Store is configured "On". The refresh works fine against the Microsoft provider. It was working a few months ago.
Microsoft.Azure.Mobile.Client v3.1.0
Microsoft.Azure.Mobile.Server v2.0.0
Browsing directly to https://[my-website].azurewebsites.net/.auth/login/google returns "You have successfully signed in"
Browsing directly to https://[my-website].azurewebsites.net/.auth/me returns [{"access_token":"ya29.Gl3ZAw6B1H0cT_e6vRlHgwQd0U-bcDSKo_CGQ9wKwPH8H-EbtNojP61JSzDaiIgSzU14PrT3QRb14NsFPhFYrU8ikCPGkhwKkZMAtHCNSdzDhTPm5cl89VrAlNc3vRU","expires_on":"2017-01-20T15:00:21.3928445Z","id_token":"eyJhbGciOiJSUzI1NiIsImtpZCI6IjZlYzMwOTBlZjgyM2YxMWFhN2VhNDE0N2FlZWM1Zjk0YmViNWZkMDMifQ.eyJpc3MiOiJodHRwczovL2FjY291bnRzLmdvb2dsZS5jb20iLCJpYXQiOjE0ODQ5MjA4MjEsImV4cCI6MTQ4NDkyNDQyMSwiYXRfaGFzaCI6IlhHa3dqOFpiZU9GX2N3SmpqeEpMRnciLCJhdWQiOiI3NDgwNzM0Njg2NDktanRtNTl0N21sY3NjaTg5bG9rYnV2c2VvYW5uMjhiZ3EuYXBwcy5nb29nbGV1c2VyY29udGVudC5jb20iLCJzdWIiOiIxMDE4MTI5MTIzODE5MTgwNDA4NDciLCJlbWFpbF92ZXJpZmllZCI6dHJ1ZSwiYXpwIjoiNzQ4MDczNDY4NjQ5LWp0bTU5dDdtbGNzY2k4OWxva2J1dnNlb2FubjI4YmdxLmFwcHMuZ29vZ2xldXNlcmNvbnRlbnQuY29tIiwiZW1haWwiOiJnY3JvY2tlbmJlcmdAZ21haWwuY29tIiwibmFtZSI6ImdlcmFyZCBjcm9ja2VuYmVyZyIsInBpY3R1cmUiOiJodHRwczovL2xoNS5nb29nbGV1c2VyY29udGVudC5jb20vLVpINUxBQ1RhQTRJL0FBQUFBQUFBQUFJL0FBQUFBQUFBQUFBL0FLQl9VOHRpamZ5ZUN3Qk9tWUxzTmM4QUZJcTNDVGJhVHcvczk2LWMvcGhvdG8uanBnIiwiZ2l2ZW5fbmFtZSI6ImdlcmFyZCIsImZhbWlseV9uYW1lIjoiY3JvY2tlbmJlcmcifQ.Qie3hRwKP-mbzMp3gzWatmQdLLVw3Ae7PXw1Ly8Se7-EQWBPgky0TsQ-fvZIasiHaq1tQu9lXyNu9qYqaaAvKxKCGxRE5yYhC76Yar_rQig14lf42bMRYQ3ADzwsPZ0yUbEpk-h4_HU5Ld1lNqYG-hgzEdUsJm_uspJk7FggwcfuPw-YQJr-GXbqd2Om9fmgGPrPrsFy7EzPGL27q_BIY3cOLEVX0e3tbAAVhxFCri835nBKdkYOP9X2g6wSuMWCq6iPOjFzErhVYR_WUwi5H-UW6mJHswcAfs_3Hwwt9RzCqfcyS1ZaehQVJE5B3uvK9WmAOrbD7uyEQmSli_zRWw","provider_name":"google","user_claims":[{"typ":"iss","val":"https://accounts.google.com"},{"typ":"iat","val":"1484920821"},{"typ":"exp","val":"1484924421"},{"typ":"at_hash","val":"XGkwj8ZbeOF_cwJjjxJLFw"},{"typ":"aud","val":"748073468649-jtm59t7mlcsci89lokbuvseoann28bgq.apps.googleusercontent.com"},{"typ":"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier","val":"101812912381918040847"},{"typ":"email_verified","val":"true"},{"typ":"azp","val":"748073468649-jtm59t7mlcsci89lokbuvseoann28bgq.apps.googleusercontent.com"},{"typ":"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress","val":"[my-googleemail]"},{"typ":"name","val":"[my - name]"},{"typ":"picture","val":"https://lh5.googleusercontent.com/-ZH5LACTaA4I/AAAAAAAAAAI/AAAAAAAAAAA/AKB_U8tijfyeCwBOmYLsNc8AFIq3CTbaTw/s96-c/photo.jpg"},{"typ":"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname","val":"[my-givenname]"},{"typ":"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname","val":"[my-surname]"}],"user_id":"[my-googleemail]"}]
Browsing directly to https://[my-website].azurewebsites/.auth/refresh returns "You do not have permission to view this directory or page"
If I repeat those steps with "microsoftaccount" the last refresh step works.
From Azure request tracking:
107. -GENERAL_FLUSH_RESPONSE_START
0 ms
Informational
108. -GENERAL_RESPONSE_HEADERS
Headers
Content-Type: text/html
Server: Microsoft-IIS/8.0
X-FE-DATA: AppId:Unknown-StatusCode
X-Powered-By: ASP.NET
DWAS-Handler-Name: BEGIN|403|80|0x0|CONFIG_SUCCESS|ExtensionlessUrlHandler-Integrated-4.0|###.##.##.###|\###.##.##.##\volume-4-default\&ApiApp=0
0 ms
Verbose
109. -GENERAL_RESPONSE_ENTITY_BUFFER
Buffer
You do not have permission to view this directory or page.
0 ms
Informational
110. -GENERAL_FLUSH_RESPONSE_END
BytesSent 400
ErrorCode The operation completed successfully.
(0x0)
Turns out that, with Google logins, refresh tokens are only issued upon the first login. I moved my Azure website and repointed the OAuth client settings so I was able to login but the Token Store no longer had a copy of the refresh_token sent with my initial Google login. Found the rest of the answer here.
Not receiving Google OAuth refresh token
According to your detailed information, I noticed that when you browsing directly to https://[my-website].azurewebsites.net/.auth/me, the response did not contain refresh_token. To isolate this issue, you could refer the following steps:
1.Browser https://brucechen-mobile.azurewebsites.net/.auth/login/google?access_type=offline and login with google account;
2.Access /.auth/me to retrieve my logged information as follows:
3.Browser /.auth/refresh to see whether you could get the response with 200 http status code.
Also, you could follow this official tutorial about refreshing user logins in App Service Mobile Apps to troubleshoot this issue. Additionally, you could leverage Fiddler to capture the detailed response when you invoke MobileService.RefreshUserAsync().