We are using parse.com sdk in our xamarin mobile app to authenticate our users. After the user logs in, we would like to store the session token in the local secured storage to log him automatically when he uses the app next time.
However, in parse.com sdk for Xamarin, the session token on ParseUser class is not exposed. How can one get the session token? Or is there an alternate way to cache authentication details locally?
This website talks about how they are updating their sessions : http://blog.parse.com/announcements/announcing-enhanced-sessions/
Right here they talk about how to upgrade you application to use the new sessions: https://parse.com/tutorials/session-migration-tutorial
Basically you need to set: ParseUser.EnableRevocableSessionAsync(); right after you initialize your ParseClient, in the global asax in .net probably.
Then you can do this:
var session = await ParseSession.GetCurrentSessionAsync();
var token = session.SessionToken;
From then on you can use the following to get the user:
await ParseUser.becomeAsync("session-token-here");
Related
Currently, I'm developing an app service using Microsoft M365 authentication. The problem comes when the user has already logged out, but the token provided by Microsoft is still valid, and can still be used to access my backend API. I've tried to revoke it using Microsoft graph
GraphServiceClient graphClient = new GraphServiceClient( authProvider );
await graphClient.Me
.InvalidateAllRefreshTokens()
.Request()
.PostAsync();
But another problem is that all my sessions are revoked too, so is there any way to implement a blacklist to store the token? I can only use MSSQL Server to store data.
I want to do something very similar to this tutorial, in which I'm getting the authCode from web client and sending that authCode to a Java BE app to get credentials of an user and then, using the credential to gain access to google sheet api to create a spreadsheet on user's drive.
According to google-api-java-client/oauth2 doc:
GoogleCredential takes care of automatically "refreshing" the token,
which simply means getting a new access token.
Would I still be able to take advantage of the above statement, in which GoogleCredential automatically refreshes the token if I'm authenticating and asking for permission on the client web app - aka, I call the grant offline request on web app and then, getting the actual GoogleCredential in a Java BE app (using the authCode)? If so, how does that work? Why would others suggest to store the refreshToken in a db?
If I do decide to store in a db, would storing the refreshToken with the key as my app's unique identifier for a user be OK (instead of using the suggested sub identifier)? Is there a limit on the amount of time I can call the token to get a new accessToken per user? Even if an accessToken hasn't expired, is it better to just get a new accessToken for every new request (seems more secure)?
I'm currently developing an identity 4 server, an API protected by scopes defined on the identity server and the mobile app server which will consume information from the API.
By now I already got a good grasp of how to use the authorization and access tokens and how to perform the correct flows, however I got into a dilemma when I started looking at the user session between the mobile app and server. After receiving the access and identity token, which basically serves as confirmation of user login/authorization, which would be the "proper" way to store it and keep the session alive with the app?
Initially I thought of using using cookies, but was told it doesn't work well with mobile apps (I barely know anything about android/ios), to which I followed by considering the creation of JWT on the server, which seemed wrong considering the existence of the identity server that was already producing tokens. And with this, how would I related the session to the access token to perform the API requests?
TLDR:
After fetching access and id token for the client, what "proper"
methods are there to keep sessions alive between client and mobile app?
How to relate the session to the access token to use when API requests are necessary?
Thanks !
For a modern native mobile app I'd suggest using the authorization_code flow (via the default browser on the device) with PKCE and storing a refresh token in the secure enclave of the device. This can then be protected by built in PIN or biometric features.
With that (carefully protected) refresh token you can maintain a long lived session without the need to do front channel (i.e. web browser) interactions with the OIDC service.
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);
We would like to enable WeChat Login on our iOS client that is connected to a Parse Server backend on Heroku. From reading through the PFFacebookAuthenticationProvider, it seems that we need to write a custom authentication provider for WeChat.
WeChat Login is based on OAuth 2.0. It works as followed:
1. From our app, an authorization request is sent to the WeChat app installed on the same phone. WeChat app is called to the foreground.
2. After user approved the authorization request, a code (NOT the access token) is sent to our app.
3. With the code and our app id and app secret, our server can then call WeChat API and get the appropriate user id and access token from WeChat. This step has to happen on our server, as we cannot include the app secret within our client app.
On the WeChat documentation, it is strongly recommended that we keep the access token strictly in the control of server (anyone with the access token can make requests to WeChat API and it will be counted towards the usage limit for our API calls).
If we are to follow this practice, we cannot save the access token in the authData field of the user. Would it be acceptable to save only the code and id from WeChat into the authData and save the access token to another class that only the master key has access to? This obviously requires us to write a custom AuthAdapter for the Parse Server.
Or is there a better way to implement this custom auth? The custom auth documentation for Parse Server is pretty thin and I plan to improve it after I can get it working for myself.
You can definitely update the auth adapter to exchange the code for an access token server side. The logic would be similar to other adapters, failing to login/signup if the server is unable to process the code to access token exchange.
Here
https://github.com/parse-community/parse-server/blob/master/src/Adapters/Auth/wechat.js#L7
If the authData object has that code, you can add additional logic to exchange it.