I have a backend running Django 1.7 and a front-end developed separately with Bootstrap. The front-end talks to the backend through a REST API that I want to protect with OAuth2.
The question is: which grant type should I use? I trust the people working on the front-end but it does not mean I trust Javascript :-) I can't decide whether I should choose the Implicit grant or the Resource owner password-based.
Any experienced advice?
Especially when working with an API that is not on the same domain or server as your front end, it's usually better to use something like the web application flow for OAuth 2. This is typically referred to as the implicit grant, and uses the grant_type of token.
This way you won't need to worry about sending credentials across the wire, like you would need to for the resource owner password credentials grant. Along the same lines, you also don't have to deal with hiding private keys for the authorization code grant.
With the implicit grant, only the OAuth token must be stored on the local machine. This should be better, as the token should be able to be revoked quickly in the event that the token become public or something else forces it to be invalidated. The user should be logged in on the API server when the authorization request is made, but most OAuth providers support a custom login page that can be used as well.
With the password credentials grant, both the username and password must be stored on the local machine which requires you to additionally secure them. They are also considerably more difficult to revoke if the need arises.
Related
I am planning to create a single page web application and all user authentication would be handled by AWS Cognito. By reading through some of articals, they all suggest using "code" grant flow + PKCE rather than implicit flow since implicit flow is deprecated in OAuth 2.1
I created a test user pool with AWS Cognito, by using Postman I successfully get access_token, id token and refresh token with code grant flow + PKCE.
I double checked with AWS Cognito Doc, seems refresh token will always be returned if using code grant flow and I cannot find anywhere in AWS console to disable returning refresh token. So just wondering how can I protect refresh_token? Cookie or localStorage can not stop XSS.
It is usual to route requests for tokens via a backend, eg a utility API, which also represents the refresh token as an HTTP Only SameSite=strict encrypted secure cookie. See this crypto code for an example.
The backend component also enables you to use a client secret, in addition to PKCE, which improves security a little. Cognito supports this, so I'd recommend using both.
BEST PRACTICE
OAuth for browser based apps recommends this approach. Stakeholders often expect you to be using the backend for frontend described, and it will make life more comfortable if you have to explain your app's security.
XSS
With the above HTTP only cookie approach, malicious code would not be able to steal your refresh tokens, and this is therefore the recommended way to handle them.
If your SPA has XSS vulnerabilities, then malicious code might be able to steal your data though, regardless of whether tokens or cookies are used to access data. Therefore it is critical to implement XSS protection carefully, regardless of your OAuth solution.
Is it possible to use AWS Cognito User Pools as an authentication and authorisation provider for a Spring Boot app running in EC2?
The user pools seem to provide a lot of the regsiter/login/email/forgotpassword etc plumbing, that I can make use of in an AngularJS front end.
If the front end does all the auth (in javascript), can a java (spring) backend verify tokens passed to it from the front end, and if so how?
Or, can/should the calls to Cognito come from the backend, and again, if so how? Do I need to use the AWS Android mobile SDK?
(I've looked at Lambdas and Api Gateways but they are not what I am after at the moment).
Either one of those options should work, depending a bit on your app requirements. The former does have the benefit of sending user credentials over the wire less often than the latter.
If you want to verify the tokens with your first suggestion, you could do one of a few things. Cognito vends an id token, a refresh token, and an access token upon a user authenticating. Any call that takes an access token (i.e. GetUser) does validation on that access token. Alternatively, you could make a call to refresh the tokens, which will do validation on the refresh token. More information on the tokens Cognito vends is available here. Token refreshing is done through the Cognito auth flow, using challenge name REFRESH_TOKEN or REFRESH_TOKEN_AUTH.
If you opt to go with the second one, AWS does have multiple SDKs for various languages, including Java. These all support the Cognito APIs, but Cognito does use SRP to sign users in. The client side calculations are fairly complex, so you might not want to take that on yourself. You could rip our calculations from the SDK on Github, or you could use the admin no SRP flow described here.
Django Oauth Toolkit docs don't describe the redirect uris, authorization grant type, or client type fields when registering your application.
The tutorial says to set client type to confidential, grant type to password, and leave uris blank.
What do the other options do?
e.g. What is client type public vs confidential? What do the grant type password, credentials, authorization, implicit do? And what are the redirect uris for?
I have found sparse information about them but no actual explanations as they pertain to django rest framework and django oauth toolkit.
You'll get answer to all your questions once you read about Oauth2 Protocol from here
But I'll try to answer your questions in brief:
I'll be using the words client and Resource Server frequently. In Oauth2 protocol, client means the system which accesses resources, data or service. (It could be your mobile app or javascript app consuming REST API's of your API Backend (or Resource Server) . If you have implemented Facebook login in your mobile/JS apps, chances are, your API backend requests Facebook for user's information. In that case your API backend is being a client and Facebook is Resource Server)
Client Types:
Client type is either confidential or public depending on whether that client can keep it's client_secret a secret. (For example, an AngularJS app cannot keep it's client_secret hidden, since anyone can do "Inspect Element" in a browser and search for it, so such a client has to be registered as public.)
Authorization Grant Types:
There are four kinds of Authorization Grant Types in Oauth2 protocol.
Authorization Code:
In this grant type, the client requests for an authorization code first, then exchanges that authorization code for an access token. It's a two step procedure. Use this if the client is an outsider (more on it in Resource-owner password based).
Implicit:
Usually used along with public client_type. Instead of a two-step procedure above, the client gets access token in one go.
Resource-owner password based:
This is used when there is a high degree of trust between client and Resource Server. This is the case between your API backend and your Mobile app. (There is high degree of trust between your API backend and Javascript app too, but since it cannot keep it's client_secret a secret, you have to use Implicit Grant type with it). Facebook or Google etc. will never give you this kind of Authorization Grant because, for them, your API backend is an outsider.
Client Credentials:
It is least commonly used. Please read about it in above mentioned document.
Redirect URI's:
Now, as far as Redirect URI's are concerned, they are needed only in Authorization Code or Implicit grant types (Not sure about Client Credentials one, somebody please enlighten me on this in comments).
Redirect URI is given so that the Resource Server knows where to send the access token. Imagine if you are implementing Facebook login. In that case you will go to developers.facebook.com and register your application (like you did with django-oauth-toolkit), while registering your application, you will specify a Redirect URI.
Specifying a Redirect URI is a way of saying. "Hey Facebook, send the access token on this URI". So if you set Redirect URI something like https://your_domain_name.com/token/facebook/, Facebook will redirect to your specified Redirect URI at the end of Oauth2 process and give Access Token in the form of GET parameter, like https://your_domain_name.com/token/facebook/?token=some_long_string&some=other_parameters.
I have an internal-facing RESTful web service. There are various client applications using the service, and the client apps themselves have end users. The web service needs to authorize requests based on the end user identities.
The question: What are the typical options for authenticating the end user here? That is, I want to authenticate the user, not the client application. (I don't mind if authenticating the client application is part of the scheme, but ultimately I need to know that the end user is who I think he or she is.)
One possible scheme, for example, would be to have per-client system accounts, and then have the client simply assert the user's identity (e.g. in an HTTP request header, say). So we authenticate the client application and delegate user authentication to the client. I don't think this is a very strong scheme, though, because it depends too much on keeping the system account credentials secret. I have seen too many examples of people e-mailing system account credentials around to put much faith in this sort of approach.
Another approach might be to have the client app, upon user login, use the user's credentials to get a token from the API, and then use that token for subsequent API requests. That way the authentication is user-specific without requiring the client app to hang onto the username/password credentials.
Anyway I'd like to have a better sense for the range of options I should be considering here.
The problem that you describe with "delegated authentication" is a real one. It means that a "client application" using it's credentials has access to the whole breadth of user data. This access can be used maliciously (for example a "semi-trusted" app harvesting api data) or negligently (for example an app accidentally exposing a Direct Object Reference Vulnerability - https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References)
Probably the most prevalent "token based" scheme is OAuth2 (http://oauth.net/2/), and the precursor, OAuth, which many sites choose to continue to use.
OAuth2 has a number of roles:
resource owner (the user in your case)
resource server (your api)
client (the apps you talk about)
authorization server (not clear who or what would fulfil this role in your case)
The basic scheme is that the resource owner authenticates using their credentials directly with the authorization server. They are then asked if they want to grant some information (which may just be a persistent identifier, or a description of the information exposed by your api) to some client. When they accept an 'auth code' is sent to the client and they use that (combined with their own credentials) to receive an 'access token'. This access token can then be used to authenticate against the resource server (which can check it's authenticity back against the authorization server).
Normally the way this is used is that the authorization server and the resource server are owned and managed by the same entity (for example google and facebook would fulfil this role) and then clients are independently managed.
The scheme can also be used internally within an organisation without the "explicit grant" which can still at least confirm that a specific end-user is present before releasing any data from an api.
I'm exploring basic service oriented architecture and I'm wondering how to best handle user authentication throughout the services.
As a very simple example, suppose we have a blog app that calls out to two other services:
A user/auth service for storing user data and exchanging credentials for an access token
A posts service for managing post data
Let's say a user of the application is attempting to delete a particular post and that only users with an "admin" role are allowed to do so.
The following requests would need to be made:
app -> auth
Authenticate the current user (via some sort of token). If the token is expired the app could redirect the user to a login form, etc.
app -> posts
Delete the post.
posts -> auth
Before a post is deleted, the post service needs to make sure the requesting user has permission to do so. Authenticate the current user (via token) and make sure they have the "admin" role.
This is an overly simple example but I'm curious how folks are dealing with auth throughout their services. It seems likely that each service would need to make a separate call to the authentication service in order to authorize the request. Is this the case? Are there better ways to handle auth in this kind of SOA?
Thanks!
You can implement an identity provider - Once a user authenticates with the authorization/authentication service she should get a token that identifies her. This token can identify her (roles/claims) and signed by the authentication/authorization service private key. When a service gets a security token and it is signed by a trusted authority it doesn't need to go to the authentication/authorization service again.
If your system has a higher security requirements (e.g. at the user level) you may need either elaborate claims or to access the authorization system on each request. I worked once on a system where certain types of info required authorization on every access and other types were ok with role based security - your millage may vary.