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.
Related
I'm working on a product with two apps: one a single-page web app, and the other a native mobile app. Both make use of the same backend API. Currently the user authenticates using username/password credentials to establish a session cookie. I'm planning on adding support for authentication using OpenID Connect.
For the web app, I'm looking at following the advice for "JavaScript Applications with a Backend" in "OAuth 2.0 for Browser-Based Apps". In that scenario, the authorization code gets sent to the backend, which obtains the ID token and begins a cookie-based session.
I'm trying to work out how this would work on Mobile. The "go to" implementation of OAuth/OIDC on mobile appears to be AppAuth. From what I can see, AppAuth uses a different approach where you end up doing the auth code exchange on the device to get the ID token.
Should I have the mobile app send the ID token on to the backend to prove the user identity (and then begin the session)? Is there any best practice around doing this? Presumably at least the backend would need to validate the JWT and verify the signature?
Alternatively, can AppAuth be used to do a similar flow as done on the web app as mentioned above?
The mobile case does indeed work differently, and is defined in RFC8252, which defines the AppAuth pattern. Both the web and mobile cases have this in common:
Open a system browser at the Authorization Server URL with a Code Flow request URL
Cookies are not used in mobile views, and mobile apps can store tokens securely, unlike browser based apps. The mobile app will send access tokens to APIs, and also make token refresh requests when needed.
Out of interest there are easy to run versions of each in my online code samples, if you want something to compare against. Both flows are tricky to implement though.
We are developing an application that uses a React front end website hosted on AWS using Amplify. This communicates with a .NET Core 3.1 Web API running on EC2 / Elastic Beanstalk. Cognito is used for user authentication with the Web API configured to use JWT tokens.
It works OK, but we have noticed that the Cognito provider stores the JWT access token in the browser local storage. This is what we see using F12 in Chrome and inspecting local storage.
From what we have read, storing access tokens in local storage is not advised as it makes the application susceptible to XSS attacks. Strange then, that the Cognito identity provider chooses to store sensitive information here.
If this approach is not considered safe, can the provider be configured to store this information elsewhere, such as cookies?
Alternatively, as we control both front and back ends, is there an alternative method that can be used to secure the API that does not involve tokens? Obviously the API needs to know which user is logged on to the web application in order to perform authorization checks. [Note authorization in the application is record level and defined in database tables, so it goes beyond simple user profile attributes.]
Many thanks in advance for your advice.
Doug
Security is a spectrum not a feature so it really depends on your appetite for risk vs effort. Amplify is not a particularly nice codebase, it has 500+ issues and if you look at the code you might be fairly shocked at the quality of it.
If you are using Hosted-UI then you can write code to manage the tokens yourself rather than using amplify, although you will need to learn a bit about OAuth grants and OIDC.
Be aware that the Hosted UI lacks a huge amount of features, so if you are going to use it make sure you are happy with it. Off the top of my head
no silent refresh capability in the hosted UI, so no safe way to store the refresh token.
no support for custom auth flow in the hosted UI
no passwordless support in the hosted UI
no ability to pre-populate a field in the hosted UI (e.g. username)
no ability to customise the plethora of obscure error messages in the custom UI
fixed now, but for years the email addresses were case sensitive!
An alternative is also to just use the AWS SDK to get tokens directly using cognito-idp but this also has a bunch of issues:
no code/PKCE/nonce capability so insecure in a mobile authsession
no ability to set oauth scopes, so can't use them
consequently not possible to use for OIDC
the SRP implementation is bananas and so far off spec
if you make device registration mandatory, it will deliver a working access tokens before the device is registered! (allows invisible devices for malicious logins)
We were using auth0 which was leagues ahead but we had to move to Cognito because of SMS OTP cost (min $25k per year at auth0).
I have been using AWS for over a decade now, Cognito is by far the worst service I have used, and I have used a lot! If you can avoid it, do so.
To answer the original question, yeah it's insecure. The best you can probably do is keep them in memory. If you wanted to you could probably put the hosted UI behind a cloudfront and use an lambda#edge to transform the token into a cookie instead. This has now opened you up to CSRF attacks though.
answering the original question: no, it is not safe at all.
Storing refreshtoken in any local storage accessable to any local app/script is not secure. So, the best way would be to store the refreshoten (and also the access token) in an httponly cookie or even better to store a one-time session token in httponly secure cookie could be used to get new access and refresh cookies - similarly as it is made by cognito hosted ui with XSRF-TOKEN.
See below how I would solve (and plan to solve) this issue:
Some background:
Due to GDPR regulations I think I can not use the cognito hosted ui - I have to make sure users read and accept the general terms and conditions (giving clear and auditable consent) and can review and accept cookie policies as well before they type in any user data for sign up. Nevertheless the built in hosted ui design is quite outdated and unflexible. I have an SPA website where I want to manage users, secure endpoints, etc.
So I have the following idea which is still not super secure but I think it is more secure one if you want to use js and ampify sdk and which also might answer your question:
I'll use amplify javascript sdk to let users sign up, change psw and log in (get tokenid, access token and refresh token), will make my own "hosted ui". I'll store the access token in memory only (not in local cookies and not in localstorage for sure). Access token will be used in header (bearer) to access apiGW endpoints. Access tokens will have very short expire dates. (I'd also use httponly secure cookies sent back by the apigw, as well as in the body.., then compare at BE side..)
And here comes the trick: I'd cut the refresh token into two. (Don't forget it is just a string.) I'd store the first part of the string in a local cookie (javascript can read it, if browser is closed and opened again it will be still there) and will send the other half of the refresh token to an apiGW endpoint (accessable without authentication) which will store it in a dynamoDB table (with TTL) and will send back an httponly secure cookie to the browser with a randomly generated "storagetoken" in it (which will be a key in dynamodb). There will be another unauthenticated apigw endpoint which will be called by the client whenever the client needs the full refresh token. Calling this endpoint the browser will send in the httponly secure cookie as well (same domain), so the backend will get it. As it is issued by the BE and available only in the given browser it can not be stolen so the backend will send back the stored half refreshtoken. The other half part of refreshtoken is stored in a simple cookie in the browser.
If the browser is closed and opened again client checks if there is any valid accesstoken and if not it checks if there is a half refeshtoken stored as cookie. Then ask the other part of refreshtoken assuming there is a httponlycookie also stored and it will get back the other part of the refreshtoken from the BE. In case of success the client tries to use the full refreshtoken to renew/get access token from cognito, in case of failure it will pop up the login screen.
Whenever refreshtoken is not in use it is deleted from the memory.
I know this is still not supersecure but might be a better solution than storing refresh token in localstorage.
Alternatively, as we control both front and back ends, is there an alternative method that can be used to secure the API that does not involve tokens?
I don't know anything of Amplify but in AWS Cognito what you describe is the Implicit grant OAuth flow. In AWS Cognito it is possible to use Authorization code grant where you instead of the token get a code which you in the backend can exchange for a user pool token.
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-configuring-app-integration.html
I'm creating my first SPA using NodeJS stack for development and I came to a point where I should design authentication and secure some parts of the app.
I read a lot about auth techniques including JWT, OAuth, etc. but I still didn't find something like «a real world example».
Let's assume that my task is just to secure some parts of app from public. My app isn't designed to work with 3rd party services so I see no need to use something like Google or Facebook auth. I want to use login/password and store all this data using my own database server.
I don't understand the point of having authentication stateless. I came to a simple conclusion that I can design authentication in this way:
I store users logins and passwords in my database.
User auth means that user enters his credentials, server checks it and creates token. Then server saves this token into database. User saves token using browser local storage or somewhere else if it's not browser environment.
On each request client sends this token, server checks that this token exists and responds appropriately.
User can login from different devices, we just create multiple tokens for him.
We can end specific session or all sessions by just deleting user tokens from database.
We can manage tokens in a way we want, for example server can check expiration time and invalidate (delete) token.
Is it OK? JWT require additional implementation if we need to invalidate token, I saw different examples, all of them were based on storing invalid tokens but what's the point of that if we can just store valid tokens? We already lose statelessness by implementing this storage.
I see that I can just use cookies instead of implementation described above but I don't like an idea to use cookies in RESTful app because it really depends on browser-like client environment.
What are the disadvantages of just storing tokens on server?
I have implemented one project in which user authentication is required and token is stored into database.
You can find that example here.
You are describing the traditional authentication approach using session cookies. The server stores a session for each connected user identified by a sessionid. The sessionid is stored by client in a cookie and sent in each following request to identify user.
You can use this method perfectly, both in browsers or mobile devices (using the device storage instead of a cookie)
The drawback is that it requires many server resources to keep sessions open and requires database queries at each authentication to retrieve user data. This is what JWT solves. The user information goes in the token itself, and is reliable because it is signed with the secret key of the server.
JWT has its own drawbacks, for example it is not useful if you need to have a revocation list, because them will require server storage.
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'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.