We have a situation with our Nativescript Angular App. We use OAuth 2 with PKCE for our authentication process but my team is fairly new to the world of mobile development.
From my research it would seem best practice suggests the lifespan of the refresh token should be anywhere between 2 weeks and 2 months. Currently our access token lifespan is set to 2 minutes and our refresh token lifespan is 30 mins. This means our users have to login every 30 mins using their username and password which isn't ideal for UX and we've received a lot of criticism for it.
Our login page uses a WebView so we considered also trying to auto-populate the form fields with a securely stored version of the username and password but then realised this can't really be done and isn't great for security.
So to improve the login process and make it more seamless, we're looking to setup face/touch ID with a pin code fallback. This means we'll have to push the lifespan of the refresh token to say 2 months or as long as possible — this seems like the best approach moving forward.
That said, the other problem is we also have a website which uses the same authentication server so if we change the Keycloak settings it'll change it also for the website as well which will create more work for the web team.
So my question is should we be using a separate authentication server just for mobile access?
I would suggest you to use offline tokens that never expires. Check this https://www.keycloak.org/docs/latest/server_admin/index.html#_offline-access
Basically in authentication process you pass additional scope named offline_access and instead of regular refresh token auth server returns offline token.
So my question is should we be using a separate authentication server just for mobile access?
If you use separate server (realm) for mobile app then you will have separate user, client and session collections and you will have hard time integrating additional applications with auth server.
Related
I have a public-facing application that uses ASP.NET Core Identity to store first-party logins, and no intention of using third-party IdPs like Facebook or Google. I want to build the front-end in React, and the application comprises an API fronting a couple of back-end services to which I'll need to forward JWTs for authorisation.
The plan so far is to use Identity Server 4 as the IdP for the project, backing it into the ASP.NET Core Identity data stores.
Current guidance is to use Authorization Code Flow with PKCE, which would require redirection to the IdP, two sets of styling etc.
In this scenario, where there is no possibility of a third-party IdP, is Resource Owner Password Grant still highly discouraged? On the face of it, it gives a neater experience:
User populates React-based login page
XHR POST to IdP with credentials (modulo an MFA challenge)
IdP returns an access token, React app subsequently uses that for future requests to the API
What issues will I introduce by pursuing the ROPC grant in this specific situation, vs accepting the need and duplication involved in a redirect-based flow to the IdP?
AMOUNT OF WORK
This is one of the big issues. As well as a login screen you'll have to make sure other areas such as Forget Password also work. If you build a second app you'll need to make it work there also.
EXTENSIBILITY
This article summarises problem areas. One of these is no scope to ever extend login solutions.
SECURITY
Token refresh does not (usually) work with ROPG, which leads to long lived access tokens and other complexity. Also, with OAuth it is recommended that the app never sees credentials.
From a security viewpoint it looks more modern to redirect the user - all the big providers do it - eg Google, Microsoft.
BRIDGING SOLUTION
As you say, if the password is private to your app it may not be the worst thing in the world. Capturing a user's Google password in your app would be a bad thing though.
ROPG has its uses but does not have much of a future - it is deprecated in OAuth 2.1 and providers will be getting rid of it. So I would also recommend what LalitaCode suggests ..
You can create a React based Identity Server login page for Authorization Code flow with PKCE instead of using MVC UI if you want. It is just extra work and complicated. I would recommend you just style the Identity Server MVC UI to look exactly like your frontend SPA. This is the simplest way and the path I took when I did a project with Identity Server(with Angular as front end).
I am having difficulty understanding Hybrid flow with mobile application. I am using code id_token Hybrid flow provided by Identity Server 4 in .Net.
Here is my scenario.
All mobile request will go to backend server and backend server will forward request to different APIs on user behalf.
When user first time login
He will be redirected to identity server
A mobile web view will be opened
User will sign in using credentials
identity server will send Id Token and Access Code to Back end
Server
Back end Server will swap Access code for Id Token and Access Token
What token will be returned to mobile application to provide that user is valid. And is it responsibility of Back end server to get new access token without prompting user to re login until user sign out?
Is there any step wrong in above scenario ?
For mobile clients its recommended to use Authorisation code flow along with PKCE. Please read through these two answers to grasp some idea why its suggested Link-1 & Link-2.
Also, RFC8252 provide some best practices application for Native Apps (mobile clients are native apps.!). In that, it recommend not to use web-views.
here is a quote from RFC8252-overview
Previously, it was common for native apps to use embedded user-agents
(commonly implemented with web-views) for OAuth authorization
requests. That approach has many drawbacks, including the host app
being able to copy user credentials and cookies as well as the user
needing to authenticate from scratch in each app
By using web-view, you loose the true essence of OAuth 2.0. You client app get the ability to grasp end user credentials. So use the browser instead of web-view. (Please read more about embedded users agents from this link)
In your architecture, you could enable all of these, PKCE, Authorization code flow and usage of browser instead of web-view. But once the backed receives tokens, it should pass them to your client. That will be a challenge if you stick to this architecture.
But if you can make your mobile application to complete whole flow, you avoid that complexity. Once tokens are received, you may create a connection between backed server by validating tokens. Also, when tokens expire, mobile app will use refresh token to obtain new tokens.
Okay so this might be a very rookie-ish or naive question but I tried searching the internet and have resorted to stack overflow only after not finding anything fruitful. I have been reading about Token based authentication as well as Cookie based authentication. I have come across the opinion that token based authentication is better for Single page web applications but cannot clearly understand why. I will be using nodejs and angularjs to accomplish the same.
I guess that with Token based authentication as well as Cookie based authentication you mean Token authentication vs Session authentication because a token can be stored in a cookie
See this
With session based authentication the server maintains a sessions per each connected user. Client authenticates with its credentials and receives a session_id (which can be stored in a cookie) and attaches this to every subsequent outgoing request. So this could be considered a "token" as it is the equivalent of a set of credentials. This approach requires heavy server resources
Token based authentication is stateless and does not require server storage because the issued token (mainly JWT is used) contains the relevant user info and is signed with the server private key, so it is non-falsifiable. The token is stored in client side (cookie, localStorage, etc), attached to every request and validated by the server. Tokens are also suitable for REST APIs that do not require to maintain the state between each request
Forms based applications use session based authentication, and SPA often use token based authentication by the inherent advantages.
Note also that a SPA with session based authentication only will attach cookies to the outgoing request if the applicacion is located in the same domain that the server
SPAs tend to have many faces: the logged in view, the logged out view, or the restricted view. It’s all about access control. Your users are all getting the same app but they may not have the same levels of access. You’ll find yourself building access control logic for your front end and your back end.
Because tokens contain all this information, they are very portable: they can be used by your UI and your backend to make decisions. You can share them with partner services as a means of building Single Sign On services that delegate users to the correct application.
Hope this link will give you more information..
Token Based Authentication for Single Page Apps (SPAs)
I have 3 websites developed upon Angular.js 1.5.8. Now, I would like to connect them to one single sign on web application and manage their authentication from one place. Without using any external libraries or frameworks, how can i achieve this?. For instance, sending credentials from single sign on web application by simple routing at Angular.js seems very difficult. On the other hand, when user logs out from one client, how do the other websites understand that they should logout?
I think you need to spend time on reading OAuth.
https://en.wikipedia.org/wiki/OAuth
Basically it goes like this. Lets say i want to log in to stack overflow and do not want to create an account here . I choose google to provide my identity . when you try to login it goes to google and asks for my account authentication. when i chose allow, google becomes my idenity provider.
Till the time i am active on google, stackoverflow would keep getting up the token. Logout from google means my identity can now not be verified in absence of token !
I'm start building a web application where the user needs to authenticate in order to get access to different modules.
I have been working with ASP.NET MVC in the past and it was quite easy using FormsAuthentication and Server Sessions so I don't have to do roundtrips to the database in order to get the user roles or any other user related data everytime I access a web method.
What I have been reading, AngularJS won't work that way so there won't be any Server Session, etc.. So...
In case I need to verify user identity every time I access a web method do I need to consume database or there is any good practice that I can learn of?
I know there are ways to store state data in client side but how that can affect the performance of a web application?
I have seen that when a user login to an application the best way is to send a Token to the client and then force AngularJS to send that Token everytime a web method is accessed... but what about sending to the client the user sessionId (from database) and then on every web method consumption sending that and then create a filter where you check that the sessionId exists in the database so the user identify is validated?
Appreciate any advice or recommendations.
Thanks.
My take on authentication is that you do not need to bring AngularJS into picture till the user is authenticated. You use simple login page and authenticate user and then redirect him to your app page that has Angularjs. Look at my old answer for more details How to handle authentication in Angular JS application
Let me try to address your concerns.
In case I need to verify user identity every time I access a web
method do I need to consume database or there is any good practice
that I can learn of?
Once you have been authenticated that part is taken care by server and browser cookies, you don't need to do anything. How standard MVC site works.
I know there are ways to store state data in client side but how that
can affect the performance of a web application?
Since AngularJS is a SPA, there is no page refresh. Data stored at $rootScope or using service are there till one refreshes the page. Performance would be better as there are less round trips involved.
I have seen that when a user login to an application the best way is
to send a Token to the client and then force AngularJS to send that
Token everytime a web method is accessed... but what about sending to
the client the user sessionId (from database) and then on every web
method consumption sending that and then create a filter where you
check that the sessionId exists in the database so the user identify
is validated?
This is standard form authentication, and transparent to developer, whatever was required to be done in traditional MVC app for authentication would work here. You don't have to worry about sessionids, tokens etc. To get users identity on the client, you can write a angularjs service with methods such as getUser to get the current logged in user. But i warn you that the authorization related decision should still be done on server.