Why when user is signing in with Facebook([QBUsers logInWithSocialProvider:#"facebook" scope:#[#"publish_stream"] delegate:self]), session token changes? And how i can get this new session token?
After logging in in delegate you specified method completedWithResult: will be fired. This method will get object of class QBUUserLogInResult, which contains socialProviderToken field. This is your new session token.
Related
I issue an access token along with a refresh token upon successful login. They are both saved in same site cookies in the browser. A custom middleware will put the token in Authorization header before the authentication process. This middleware will also check if the access token is expired, if it is it will try the refresh token, if validated it will save two new cookies(the new refresh token and new access token) and pass the new generated access token with the current request.
Is this how we are supposed to implement refresh tokens? If I want to blacklist a specific refresh token, should i save all refresh tokens in the database?
string auth = httpContext.Request.Cookies["AuthToken"];
if(string.IsNullOrEmpty(auth))
{
httpContext.Request.Headers.Add("Authorization", $"AuthorizationCookieNotFound");
return _next(httpContext); //That token wont be accepted i just
// put it there for the sake of demonstration
}
httpContext.Request.Headers.Add("Authorization", $"Bearer {auth}");
return _next(httpContext);
You have to be very careful while storing refresh tokens and they must be kept at some secret place otherwise you know the consequences.
I assume you are using "Aurhorization Code flow" here. So it's a good idea to store the refresh tokens in the db against the username and you can add an extra column e.g "IsRevoked" for status purpose and then you can blacklist/whitelist the tokens basked on the username and isrevoked status.
See this link about storing tokens.
I want to be able to invalidate any action token for a user within an authentication flow.
The scenario is the user sends a reset password and receives an email with an associated action token. The user then sends another reset password and gets another email with a different action token associated. For the length of the first action token expiry time the user can utilise the links in both emails - however I'd like to be able to identify within my custom reset password authentication flow that the user is requesting a duplicate action request and invalidate their earlier action token(s) so that only their latest reset password link works.
I've been looking at the below objects but had no luck finding an action token store associated with all the user's activity rather than just their current authenticated session.
AuthenticationFlowContext context;
List<UserSessionModel> sessions = context.getSession().sessions().getUserSessions(context.getRealm(), user);
RootAuthenticationSessionModel parentSessions = context.getAuthenticationSession().getParentSession();
ActionTokenStoreProvider actionTokenStore = session.getProvider(ActionTokenStoreProvider.class);
Thanks in advance.
I've resolved this by maintaining a Table of users and action tokens per flow. This means when the user initiates a new action flow I can grab the previous token if still valid and use the ActionTokenStoreProvider to invalidate it replacing it with the new token. I am still hoping keycloak has some internal mechanism to manage this rather than my own custom code. Drop a solution if you know of this!
I am using client-flow authentication in Xamarin.Forms and am trying to figure out how to handle when an authentication token expires.
My Code:
Upon initial login, the user logs in with the native Facebook SDK and I pass the access_token to MobileServiceClient to get back an authenticated user.
var user = await client.LoginAsync(MobileServiceAuthenticationProvider.Facebook, token).ConfigureAwait(false);
I then save the user's UserId and MobileServiceAuthenticationToken in local settings (using the Xam.Plugins.Settings plugin).
The next time the user opens the app, I set the user from settings and skip manual login:
if (!string.IsNullOrWhiteSpace(Settings.AuthToken) && !string.IsNullOrWhiteSpace(Settings.UserId))
{
client.CurrentUser = new MobileServiceUser(Settings.UserId);
client.CurrentUser.MobileServiceAuthenticationToken = Settings.AuthToken;
}
My Question:
This works great. However, I know that the MobileServiceAuthenticationToken has an expiration on it. What will happen in my app when the expiration date is reached? How do I refresh the token without requiring the user to re-log-in to Facebook? I have tried the MobileServiceClient's RefreshUserAsync() method, but I get the following exception:
Microsoft.WindowsAzure.MobileServices.MobileServiceInvalidOperationException: Refresh failed with a 400 Bad Request error. The identity provider does not support refresh, or the user is not logged in with sufficient permission.
Is there a way to test this? (since the token expiration is 3 months from now.) Thanks for the help!
Microsoft.WindowsAzure.MobileServices.MobileServiceInvalidOperationException: Refresh failed with a 400 Bad Request error. The identity provider does not support refresh, or the user is not logged in with sufficient permission.
Since you are using client-flow authentication, you could not use RefreshUserAsync() for refreshing the MobileServiceAuthenticationToken. Your mobile backend does not cache the related access_token and refresh_token for renewing the authentication Token.
Is there a way to test this? (since the token expiration is 3 months from now.) Thanks for the help!
AFAIK, the MobileServiceAuthenticationToken expiration is one hour by default, you could use https://jwt.io/ to decode your token and check the exp property, then use https://www.epochconverter.com/ to convert your timestamp to human date.
For your requirement, you could follow adrian hall's blog about Caching Tokens and refer to the IsTokenExpired method for decode your authenticationToken and check the exp, then manually renew the authenticationToken.
Per my understanding, there are two approaches for you to achieve your purpose:
You need to cache the facebook access_token in your mobile client side, after you manually checked the authenticationToken and found that it expired, then you could manually execute the following code for renewing the token and explicitly update your local cache.
var user = await client.LoginAsync(MobileServiceAuthenticationProvider.Facebook, token).ConfigureAwait(false);
Note: Your facebook access_token has the Expiration Date, so if your access_token expired, then you need to force the user to log into Facebook again before acquiring the new authenticationToken.
Or you could build your custom endpoint for refreshing the authenticationToken and explicitly set a long lifetime for your new authenticationToken, details you could follow this similar issue. Note: For your client-side expiration processing, you need to renew the token before your local authenticationToken is about to expire.
I'm creating a new user (server side, nodejs) using new (Parse.Object.extend("_User")) then set username, password, and call .save() on it. I see that a new session is being created in the database.
I do expect that behavior for signUp but does save suppose to do that?
You should use the signUp method on the user objects in order to signUp the user with parse-server like mentioned in here
After signing up parse-server will return a session token in the response, so you can store it and use it the next time the user is returning back to your app. The same is relevant for logging in a user back with your service.
I have an MVC4 web application that uses LinqToTwitter to display Tweets when a user's profile page is visited, if they have a Twitter handle.
For this I use ApplicationOnlyAuthorizer:
var auth = new ApplicationOnlyAuthorizer
{
Credentials = new InMemoryCredentials
{
ConsumerKey = "twitterConsumerKey",
ConsumerSecret = "twitterConsumerSecret"
}
};
auth.Authorize();
My problem is that I have found that auth.IsAuthorized always returns false, even when I have call Authorize() and am successfully able to make calls to Twitter. And also, I have found that if I call Authorize() in every call made to Twitter, that an unhandled exception is thrown if I repeat the call enough times.
It seems quite important that I am able to know if auth is authorized before I make the call to Twitter. For now, I have put in a quick fix where I store my own IsAuthorized Session variable - but am not sure how reliable this is, because the Session variable could outlive the actual authentication itself?
Any advice on this would be appreciated.
The first time you authorize, Twitter will return a bearer token. After Authorize, you can grab this from the auth.BearerToken property. On subsequent calls, you can re-use the same bearer token. The bearer token doesn't expire, unless you invalidate it. Twitter's recommendation is that you use the bearer token for about 15 minutes and then re-authorize after that.