-I have a SPA application in javascipt
-A webapi service .net
-A token service in a same project .net
Problem 1
Spa application make an ajax request to token endpoints using grant_type password. in return it gets back
a token that is saved in localstorage and later on used for authenticating webapi .
1. Is this the correct approach for SPA authentication ?
2. Is password grant type correct approach ? or I need to use some other flow to make it secure. In oauth documents it written it should not be used.
3 I am concerned about security of token as it can just be copied and pasted. How to secure it?
problem 2
Custom SSO with token service
Now i have an another application using same architecture . Like application A and B. Uses same archtecture. I want to
use token service of application A to issues a token to application B to log into application B.
Token issued by A to application B can be dencrypted and I can create user identity.Now how can we login to application B
as it also follows a token based approach . So here should I login to application B by creating a new local accesstoken
issued itself using information from token issued by application A.
Is this the correct approach for SPA authentication ? 2. Is password grant type correct approach ? or I need to use some other flow to make it secure. In oauth documents it written it should not be used.
Using the resource owner password credentials grant is fine when developing your own application but defeats the whole purpose of OAuth2 when using it with third-party client applications, as it's the only flow where the user password is directly exposed to the client application (which breaks the principle of least privilege).
You may consider using the authorization code or the implicit flow instead, but it's not necessarily "more secure" and often considered as an overkill by people looking for a simple "token alternative" to password authentication.
3 I am concerned about security of token as it can just be copied and pasted. How to secure it?
Since you're developing a JS app, bearer tokens are directly accessible by the user. There's nothing you can do about that (it's similar to the security level of cookies, that can be easily copied and moved to a different environment by the user himself).
To protect access/refresh tokens against remote attackers, all you can do is making sure your JS app is not impacted by a XSS breach, that would allow stealing them or making malicious API calls on behalf of the user.
So here should I login to application B by creating a new local accesstoken issued itself using information from token issued by application A.
SSO won't really work with non-interactive flows like the resource owner password credentials grant, as the user is not logged in to the authorization server in this flow (i.e no session cookie is created when making a grant_type=password request).
You should consider setting up a central authorization/authentication server supporting an interactive flow like the authorization code or the implicit flow to support this scenario.
Related
I'm new to security domain, and recently I have learned about Oauth2.0/OpenID connect and JWT tokens. I have an existing REST based web application where I need to implement security.
Server
Application A: Spring boot back-end application sever, with some RestEndpoints exposed connected with Mysql database.
Front End
Application B: Spring boot Web Applicaiton which have some JSP pages for login and some other template features(Also connected with same Mysql database used by back-end server).
Application C: Inside application B we have an Iframe in which Angular app is running, angular app calls the back-end server and show data.
Also in future we want to use SSO for our application as well.
Current Security
At the moment we don't have any security on back-end server (i.e We can simply call RestEnd points without any authentication), Application B has basic login security implemented via spring security. User logins on application B and then he/she can use application C (Angular) as well. User session is managed at Application B, when session expires users forced to logout.
Oauth2 Authorization
What we are trying to acheive is make the server (Application A) as Oauth2Resource server and Oauth2Authorization server. Application B (JSP front end) remove database connection from it as well as the login controller, application B will call oauth2 server for authorizing user with "password" flow, when application B will receive access_token and refresh_token it will then somehow pass it to Iframe (angular app) to store these tokens inside cookie and on every subsequent request to server angular will add access token to it.
I've read articles about that Oauth2.0 have deprecated the use of "Implicit Flow", and they prefer to use the "Authorization Code Flow". I am having a very hard time to understand how this flow can be used for single page applications(SPA like angular). Also where to store the access_token and refresh_token if I use the implcit flow? I'm aware that storing both tokens in cookies is not a good practice.
Also how to manage user session now? what I have gathered so far is that, on requesting resource server with Bearer access token, when we get unauthorized response, we'll then request for new access token with help of refresh token, but in case when refresh_token is also expired I will force user to login screen. Is this right approach?
Sorry for the long context, any help will be highly appreciated. Thanks
A couple of recommendations:
Use a low cost cloud Authorization Server, eg Azure or AWS
Focus on building great UIs and APIs, which is not easy
In terms of flows, use the Authorization Code Flow (PKCE) and the OIDC Client library to manage SPA security.
A good starting point might be my First Tutorial to understand how to get integrated. Generally:
SPAs use short lived access tokens and should store them in memory
SPAs traditionally do not use refresh tokens directly
Feel free to post back follow up questions and I can point you to additional resources. You should aim to avoid running the SPA in an iframe by the way - see my other answer.
I'm struggling theese days on the possible way to configure an Authentication + authorization system to consume a REST API from a mobile application.
Scenario:
We've developed 3 independent portals for a big customer that serves several users.
To enable a SSO for the 3 portals we've implemented a SAML authentication system using SimpleSAMLphp.
Every portal has a service provider and they make assertion requests against a central IdP.
The IdP checks username and password against a database where passwords are hashed and stored during registration.
After the login, the authorization on the portals is handled by the session on the server, and so far everything was fine.
Now the customer asked us to develop a mobile application that will require the users to login and access several of their protected resources collected during the usage of the 3 portals.
We've decided to develop a frontend application using ionic that will consume a REST API made in node.js that will serve all the data (both protected and unprotected resources).
Now here comes the question: to authorize access to protected resources on the Api we'd like to use JWT to easily achieve a stateless system.
The doubt is how to perform the authentication? We've the opportunity to check the credentials directly against the database skipping the SAML process, otherwise we've to implement a solution where the SSO IdP acts as authentication provider and then when an attempt is successful the API app will get the response from the idp and then issue a signed jwt to the consumer client. Is this second way a common implementation? Is it possible?
What path do you suggest to follow? The first could be very easy to achieve, but since we're using html+js for the app's frontend, if we decide to use the second solution probably in the near future we could recycle some code from the app to modernize some functions on the web portals, maintaining the jwt pattern and consuming the new Api also on the web.
I believe that in this case will be easier to ask a token to the new api using someway the logged in user's data already in the session of the portal. Sounds possible?
I hope that everything was clear, any help will be appreciated!
Thanks
The key goal here is to code your apps in the best way, via
the latest security standards (OAuth 2.0 and Open Id Connect).
SAML is an outdated protocol that is not web / mobile / API friendly, and does not fit with modern coding models.
Sounds like you want to do OAuth but you do not have an OAuth Authorization Server, which is a key part of the solution. If you could migrate to one you would have the best future options for your apps.
OPTION 1
Use the most standard and simple option - but users have to login with a new login screen + credentials:
Mobile or Web UI uses Authorization Flow (PKCE) and redirects to an Authorization Server to sign the user in
Mobile or Web UI receives an access token after login that can be sent to the API
Access token format is most commonly a JWT that the API can validate and identify the user from
The API is not involved in the login or token issuing processes
OPTION 2
Extend option 1 to federate to your SAML Identity Provider - enables users to login in the existing way:
The Authorization Server is configured to trust your SAML based identity provider and to redirect to it during logins
The SAML idp presents a login screen and then posts a SAML token to the Authorization Server
The Authorization Server issues OAuth based tokens based on the SAML token details
OPTION 3
Use a bridging solution (not really recommended but sometimes worth considering if you have no proper authorization server - at least it gets your apps using OAuth tokens):
Mobile or Web UI uses Resource Owner Password Grant and sends credentials to a new OAuth endpoint that you develop
OAuth endpoint provides a /oauth/token endpoint to receive the request
OAuth endpoint checks the credentials against the database - or translates to a SAML request that is forwarded to the IDP
OAuth endpoint does its own issuing of JWT access tokens via a third party library (if credentials are valid)
Web or Mobile UI sends JWT access token to API
API validates received JWT access token
We're in a scenario where a single page application that we develop ourselves (AngularJS front end with https server APIs in the back) opens another
web application developed by a partner of ours in a new browser tab, and where this second web application needs access to a https server API that is also developed by us.
After looking around for possible solutions, we have now created a proof of concept using IdentityServer4, where the second web application is configured as a client with "authorization_code" grant type. When all applications are running on the same domain, the third party application is able to access our https server API without being prompted for user id and password.
The implementation of the second web application in this proof of concept is very much like the solution presented by bayardw for the post
Identity Server 4 Authorization Code Flow example
My question now is:
When - in production - the second web application no longer shares domain with our application and our https server API, will a call from the second web application be prompted for username and password when accessing our http server API?
Seems, you are missing some major things. First of all any API should never ask for username and password. Instead your app(s) should put a token into each request and API should validate that token. Where the user credentials should be asked is when a user accesses your (or 3-rd party) web application. Then Identity Provider creates an Identity token (usually to be persisted in a cookie and used within the app) and access token (to be provided to APIs). Each token is issued for specific Client (app) pre-registered in IdP. Probably when been hosted at the same domain your two apps shared the identity cookie and Client Id what is not correct. In production scenario you have to register the apps separately. All the rest should work fine (if you follow the routine i briefly described at the beginning).
Chosing to post an answer myself from feedback through other channels:
This boils down to the session tracking of the IdP. If cookies are being used to track IdP session, the behavior is impacted by whether a session cookie or a persistent cookie is used.
In general, I have found that Robert Broeckelmann has great articles on medium.com.
I'm learning about O Auth 2 from here
I was wondering in the step of "Authorization server redirects user agent to client with authorization code", why doesn't the server just give the access token instead? Why give an authorization code that then is used to get the access token? Why not just give the access token directly? Is it because there there is a different access token for each resource so that you need to go through O Auth again to access a different resource?
The authorization grant code can pass through unsecured or potentially risky environments such as basic HTTP connection (not HTTPS) or a browser. But it's worthless without a client secret. The client can be a backend application. If the OAuth2 server returned a token, it could get compromised.
There is another OAuth2 flow - the Implicit flow, which returns an access token right after the authentication, but it's designed mainly for JavaScript applications or other deployments where it's safe to use it.
If a malicious app gets hold of the client id of your app(which is easily available, for example one can inspect the source), then it can use that to retrieve the token without the use of the client secret. All the malicious app needs to do is to somehow either specify the redirect URI to itself or to tap into the registered redirect URI.
That is the reason for breaking the flow as such. Note, when the client secret is not to be used as in SPA (Single Page Apps) or Mobile Apps, then PKCE comes to the rescue.
There is a reason for breaking up the authorization flow so as to keep the resource owner's interaction with the authorization server isolated from the client's interactions with the authorization server. Therefore we need to have two interactions with the authorization server. One in which the resource owner authenticates with it's credentials to the authorization server. And another where the client sends in it's client secret to the authorization server.
Please also see PKCE that deals with SPA (SinglePageApp)/Mobile apps.
i'm implementing a REST layer for an existing application. I have my userid and passwords stored in database and i would like to authenticate these credentials while calling my REST services. Note that this is a standalone application.
After investigation, I figured out 2 ways.
Basic implementation with HTTPS - this approach makes sure that
userid and password passed is not tampered by Man in middle attack.
Using Authentication Token(JWT) - user initially passes his userid
and password and server gives back an Authentication token.Once user
have an authentication token that could be used for subsequent
request.
Using OAuth 2.0 - I'm very confused in this approach. After reading the docs and specification, I found that since my application
is standalone, I need to implement Authorization Server, Resource
Server etc.
I'm asked to implement OAuth here, but i'm not convinced that OAuth is required in this scenario. I'm more inclined towards just implementing JWT(tokens)
Is OAuth really mandated in this scenario. What i understand about OAuth is it is used when you already have a service like Facebook/ Google.
Could someone pls confirm if my train of thoughts are correct and if OAuth 2.0 is required in this case?
The primary goal of OAuth 2.0 is to allow users to authenticate to use a client application via a third-party authentication provider (e.g. Google, Facebook, etc.), without exposing their credentials (typically a username/password) to the client.
In your case, if users are only ever going to authenticate to your system using their credentials in your database, then implementing OAuth 2.0 doesn't add any substantial value for you.
The OAuth 2.0 specification does define a "Resource Owner Password Credentials grant", intended for legacy use cases, that would apply to your situation: a user sends credentials, and you return an access token (that could be a JWT, if you like). If it's desirable from a management or marketing perspective, you could implement the Resource Owner Password Credentials grant and legitimately state that your application "conforms to a subset of OAuth2, as defined by RFC6749".