I want to generate a new Capability Token whenever the existing Token expires using Twilio.Device's offline handler.But this is triggered even when the connection is dropped.
Is there any way to know whether the Twilio.Device.offline(handler()) is triggered due to the expiry of Capability Token alone.
While I don't think there's a way to only trigger Twilio.Device.offline(handler()) when a token expires, you can ensure token expiry by checking for Error 31205 JWT Token Expired.
Upon log of this error you can then handle it in your application as you see fit.
Related
I'm using the AppleAuth npm package in my server to submit token requests to Apple's servers during the sign in with Apple process. (This is based off the sample server code provided with the sign_in_with_apple package in pub.dev) I have no issues submitting the authorization code to get my first access and refresh tokens.
However, when trying to test how my app would get a new refresh token, when I submit a POST request to https://appleid.apple.com/auth/token with the grant_type set to refresh_token the response I get is different than from having the grant_type set to authorization_code.
I looked at the source code of the package, and for its AppleAuth(myConfig).refreshToken(myRefreshToken) (<- pseudo code lol) the only difference in the POST payload is:
{
grant_type: 'refresh_token', // instead of grant_type: 'authorization_code'
refresh_token: refreshToken, // instead of code: authorizationCode
... // other params
}
While the initial request with authorization code returns both an access token and a refresh token, for some reason the refresh token request is only returning the access token. I really don't think it's the package causing the error, nor can I see how my code would be the source either, since the above code is the only difference.
I tried passing the access token that it returns in a new refresh token request in order to test that I can get new refresh tokens whenever necessary in the future, but it returns a 400 status error.
Am I missing something here? Is there a reason the refresh token request returns no new refresh token? Or am I missing something entirely about how the process/flow is supposed to work? I am trying to do this for the "check the refresh token once daily to confirm the user is still in good standing with Apple's servers" part of the process.
I've really been stuck on what to do at this point. I can save the identity_token.sub field in my database to check whether my user is signed in, but of course I want to make sure my user's apple ID is still valid with apple, and that they haven't revoked access. Could it be that because I tried to get a new refresh_token too soon Apple only returned the access_token?
Oh also, the app itself is a Flutter app and I am testing all of this on my iPhone 11 so it's not an Android/Web flow.
Whether you get a new 'rolling / rotating' refresh token in a refresh token grant response is generally vendor specific:
You may get a new refresh token occasionally but not always
The primary purpose of this message is to get a new access token, not a new refresh token
In terms of token handling, the client should update its tokens similarly to the saveTokens method in this sample of mine.
I've not used Sign In with Apple but I suspect proceeding as follows would be the simplest solution:
Keep access tokens short lived: no more than 60 minutes
This forces a frequent token refresh, which by default is very quick
If the user's Apple Id is revoked I would expect this to return an invalid_grant response
I have session timeout setting as 1 hours, and my initial access_token seems timeout around this time. This is excepted.
And after it timeout, i did token refresh and get a new access_token, then i observed this refreshed access_token seems not timeout in 1 hours, even 5~6 hours after, it still not expired.
So is there refresed access_token never expire? Can someone explain more about this?
Refresh token policy is managed from admin side usually and is different from the initial access token. From what you say the setting you have right now for Refresh token is probably 'Refresh token is valid until revoked'.
When you go to your Salesforce org go to Setup -> Manage Connected Apps - find the connection you are looking for and see what policy you have set. You can set it to expire in number of days, based on usage or Immediately.
I have started using spring session in my jersey rest api, is there a way we can renew the expired session token . I know that we are deleting the token as soon as it ttl is over but is there any way I can achieve this. Any help is highly appreciated . Thank you so much
This is how we solved this problem:
Based on username & password we are getting access token+refresh token. Mention grant type is password in this case.
We are saving token in session.
[access token] as key and [accesstoken, UserDetails, RefreshToken and expiryTime] as value.
Each time a reuest is coming to the server, we are checking the expiry time in the session with the current system time.
Once a token is expired. InvalidTokenException is thrown.
Catch the exception in the front end and send another request with acesstoken + refresh token + grantType="refresh_token".
Then we are checking if refresh is there in the session or not. If yes, we issue a new token and update expiry time.
Please refer this image.
I have an ASP.Net MVC site secured with SSL and am using System.IdentityModel.Services and am creating the token like this:
SessionSecurityToken token = new SessionSecurityToken(myClaimsPrincipal, TimeSpan.FromDays(1));
SessionAuthenticationModule sam = FederatedAuthentication.SessionAuthenticationModule;
sam.WriteSessionTokenToCookie(token);
When I access the site in the browser, Firebug does not display the expiry date as expected. Instead the expiry date is shown as Session:
Can anyone explain why this is please? I assume that ASP.Net can still see the actual expiry date internally when it reads the cookie? More so, where is the cookie expiration time actually set?
You're mixing two different things here:
Token Expiration is determining until when the token is valid. After that time, even if the token is attached to a request, it is considered invalid and will not be honored. Usually the expiration time is encrypted within the token itself and that means that it's controlled solely by the token issuer.
Cookie Expiration is something that is controlled by the client (your Web-Browser in this case). Once the Cookie is expired it is no longer being attached to the request. But, should the Browser decide to send it, it will work until the Token expiration has reached.
In your particular case, the Token expiration is set to 1 day, but since the Cookie expiration is set to 'Session' it means that if you were to end the session (typically by closing your Browser window) at some point before the Token expires, the Cookie will not be sent and you'll be required to login again.
After 1 day (when the Token expires), even if you're still in session, you're always required to login again.
Update (as per your comments):
Ticket expiration and Cookie expiration can be set separately simply because sometimes the ticket is not necessarily contained in a Cookie. It may be sent to the server using other methods (QueryString, custom HTTP header etc). Yet, indeed the natural thing to do is have them both set to the same expiration time.
This is also the case in your SessionSecurityToken, if you'll set its IsPersistent flag to true you'll notice that Cookie expiration is now the same as the Ticket:
SessionSecurityToken token = new SessionSecurityToken(myClaimsPrincipal, TimeSpan.FromDays(1));
token.IsPersistent = true;
I need to use Notifications via APNS in my iPhone App.
But as I read specification, I see the Token can be changed on APNS side and I have to update token on Provider side to receive notifications right.
But what will happen when Provider creates Notification and will pass it to APNS and in this time the token will be already changed?
Will I receive a Notification with old token? Will provider be notified that token expired?
Should I solve it so, that after registering I will update my Provider with info "YOU CAN SEND NOTIFICATIONS" and make a NSTimer job to update this state while app is running?
According to this:
http://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/IPhoneOSClientImp/IPhoneOSClientImp.html#//apple_ref/doc/uid/TP40008194-CH103-SW2
Thanks
If your app registers for notifications at launch, and implements the methods specified in the documentation, it will be sure to get the correct token.
If your app keeps track of what the token used to be, it can send an update to the provider as needed (or just every time it gets a token whether it has changed or not).
If the token has changed, and the provider tries to push using the old token, the provider will be notified by the push notification server that the token is not valid.