Should an Open Banking authorization server reject or accept GET /token or /register endpoint requests with a NULL SCOPE?
When looking at the specs it is clear that the SCOPE is not mandatory, however on
the registration, scopes are validated against the content of the certificate used. Without authorising a specific scope I would expect an increased risk of misuse/security issues within an immature server system where validation routines could be in their infancy.
Am I being paranoid? Is there valid scenarios where machine-to-machine authorisation is totally relevant without the use of SCOPE?
Scopes are the functionality, which is going to be used by the client app. So if no scopes provided the token can be issued, but it can't be used for anything. I think if you are implementing the server side, you'd reject every call made with token like this (if allowing null scope at all).
But since you want to validate scopes agains the roles in the client app's certificate it would make sense to reject "make token" and/or "registration" requests in case one of the scopes is not allowed by the certificate of none of the requested scopes match with roles from the certificate.
Also take into account that Open Banking UK is based on the OpenID Connect spec and there "openid" scope is required: https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
Related
I'm looking for guidance and/or best practices in implementing step-up authentication. The generic scenario is as follows: user logs in to web app using some identity provider, user then goes to some specific area of web site which needs to be protected by additional MFA, for example OTP. All functionality for the website is via REST API, authenticating with JWT bearer token.
The best description of the flow I found is from Auth0 here. Basically, user acquires the access token with scope which is just enough to access APIs that do not require additional protection. When there is a need to access secure API the authorization handler on backend would check if the token has the scope indicating that the user has completed the additional MFA check, otherwise it's just HTTP 401.
Some sources, including the one from Auth0, suggest using amr claim as an indication of passed MFA check. That means that identity provider must be able to return this claim in response to access token request with acr_values parameter.
Now, the detail that is bugging me: should the frontend know in advance the list of API that might require MFA and request the elevated permissions beforehand, or should frontend treat the HTTP 401 response from backend as a signal to request elevated permissions and try again?
Should identity provider generate relatively additional short-lived token to access restricted APIs? Then, if frontend has 2 tokens it must definitely know which token to use with which API endpoint. Or maybe identity provider can re-issue the access token with normal lifespan but elevated permissions? Sounds less secure then the first approach.
Finally, do I understand the whole process right or not? Is there some well documented and time-tested flow at all?
CLIENTS
Clients can be made aware of authentication strength via ID tokens. Note that a client should never read access tokens - ideally they should use an opaque / reference token format. Most commonly the acr claim from the ID token is used.
This can be a little ugly and a better option can sometimes be to ask the API, eg 'can I make a payment'? The client sends an access token and gets a JSON response tailored to what the UI needs. The API's job is to serve the client after all.
APIs
APIs receive JWT access tokens containing scopes and claims. Often this occurs after an API gateway swaps an opaque token for a JWT.
The usual technique is that some logic in the Authorization Server omits high privilege ones, eg a payment scope or claim, unless strong authentication was used.
It is worth mentioning plain old API error responses here. Requests with an insufficient scope typically return 403, though a useful JSON error code in an error object can be useful for giving the client a more precise reason.
STEP UP
As you indicate, this involves the client running a new code flow, with different scope / claims and potentially also with an acr_values parameter. The Curity MFA Approaches article has some notes on this.
It should not be overused. The classic use case is for payments in banking scenarios. If the initial sign in / delegation used a password, the step up request might ask for a second factor, eg a PIN, but should not re-prompt for the password.
CLIENTS AND ACCESS TOKENS
It is awkward for a client to use multiple access tokens. If the original one had scope read then the stepped up one could use scope read write payment and completely replace the original one.
In this case you do not want the high privilege scope to hang around for long. This is yet another reason to use short lived access tokens (~ 15 minutes).
Interestingly also, different scopes the user has consented to can have different times to live, so that refreshed access tokens drop the payment scope.
ADVANCED EXAMPLE
Out of interest, here is an interesting but complicated article on payment workflows in Open Banking. A second OIDC redirect is used to get a payment scope after normal authentication but also to record consent in an audited manner. In a normal app this would be overkill however.
In our project, we are using oauth (implementation - apifest) for token generation and validation. I am unable to understand the scope concept.
As per my understanding, oauth scope is used for authorization, which consists of some permission.
We have capability and role concept in our project, where:
Capability - permissions
Role - group of capabilities.
A role will be assigned to a user, based on which he functionality across application will be defined.
Role creation is dynamic.
Is this role concept the same in oauth? or is the scope defined at application level, where the users in that application will have the same scope?
I tend to think of Scopes as a permission (or entitlement) to perform some action.
A role is typically a collection of permissions required to perform a "Job" or work within a "Project"
OAuth has no concept of a "Role"
Scopes are Requested by the client but are only Granted by the Authorization Server.
Scopes requested may not be granted and additional scopes may be granted that were not requested.
Scopes are used to delimit which applications can act on the behalf of the resource owner.
If you have an application, say a voting service, at voting.example.com. You have two roles: voters, which can see a poll, and vote, and admins, which can see the full results. The voting application enforces permissions based on these roles. A local user is assigned a local role. The application is protected using OAuth, so a user can be identified by a token.
You also have a social network app, social.example.com. This app provides a page where users can vote on the voting service. It is also connected to the same OAuth authorization server.
Finally, someone else has a reporting app, reports.example.com. This app would like to allow users to see the vote tally by requesting it from the voting service. It is connected to the same authorization server.
The authorization server, say iam.example.com. The authorization server has three clients, one for each app described above. There are two scopes defined in the authorization server, voting, and reporting.
The reporting app, when you login will request the reporting scope. The actual login happens on iam.example.com which will grant the token to reports.example.com. The login form will ask you, the user, whether you grant the client (reports.example.com) the right to act on your behalf and obtain reports from the voting service (provided by the reports scope). The scope will be recorded and associated with the token it sends to reports.example.com.
Now the reporting app can make a request to voting.example.com which says, "I would like to see the voting tally" The voting.example.com app will check the token, and provided it has the reports scope, it will send back the tally.
If it tries to make a request to the voting service to vote, it should be refused by voting.example.com, because the bearer token does not have the scope allowing you to vote. This must be enforced by the voting app. The authorization server manages which client is granted which scope. Only to see the reports. This is not related to your role in the voting application itself.
OAuth itself doesn't provide a mechanism for identity validation, so you do not have a mechanism for validating who you are from the token, and what roles you have. OpendID connect (OIDC) provides extra functionality for this by providing a scoped based identity endpoint protected by the authorization endpoint which allows it to reveal your identity to the app. So if we assume you have OIDC too, then it will check, from the token, who you are. It can then check it's database to see whether you have the right role, and whether you are allowed to see the tally before sending it.
What the scope enforces, is that the reports app, using it's client, can obtain a token to act on your behalf and ask for the information. When you grant the client the scope, you are allowing it to communicate with the voting service to obtain the information.
Roles are managed by your application and with a permission system, determine who can vote, who can read the votes.
Using something like OIDC, you can extend OAuth so the token identifies who you are. voting.example.com can then check that you are a) authorized to vote (by the local logic), b) that the application doing it on your behalf is allowed to act on your behalf (through the scope attached to the token).
In a pursuit to develop a Open ID connect model for existing applications and back-end services, I am confused to choose whether Offline vs Online JSON token validation for ID Token & Access token.
My Open ID Provider : KeyCloak
My Question is around the idea about Token Validation, So I am not discussing the implementation details.
As per OIDC (Open ID Connect),
ID token will be issued to the service that is requesting resource
once authenticated
and now on the resource server side is it really necessary to verify the token with Open ID Provider (Keycloak) or offline validate the Token based on the public key.
If I go for Offline model of token validation - what are the potential implications / limitations i must face.
I am looking for ideal situations to choose the appropriate model & trade-offs discussed.
The only advantage of online validation is the possibility that user rights are revoked in the meantime. With offline validation you have proof that token is issued by your Keycloak and that nobody tampered it. Online validation for every request would be too much.
For example, a click in the frontend can result in many api calls and there is no benefit in creating dozen rest requests to Keycloak in the same second. Recommendation is to keep token lifetime shorter.
You could implement token caching and validate token online in some short periods, but what’s the point if you can just lower token lifetime in the Keycloak.
So to conclude, validate the token offline for the timeout duration ( say 5 minutes - should be configurable based on the use case) and beyond the period issue new token.
Token validation is one aspect but it is not a complete security solution. You will often find that you need data from both the token and other sources to authorize access to resources properly.
So your solution depends on how you want to authorize and also on non functional requirements such as availability and performance.
My personal preference is offline due to its separation of concerns - see my write up for further details.
on the resource server side is it really necessary to verify the token with Open ID Provider (Keycloak)
yes, you must validate ID token as defined by OpenID Connect(OIDC) protocol. Token validation have many steps, but mostly involved in signature validation, issuer validation. Once this is done you can say ID Token to valid and hence mark end user to be authenticated. This is the core principal in OpenID Connect.
Regarding offline, validation on public key is sufficient. For example, this means when your authorization server change key chain (which is rare and done when there's a security breach), you have to somehow update your key again.
Also, there exists JWT encryption (RFC7516), which adds an extra layer of security for token validation (if you are concerned about security). But if I am correct KeyCloak doesn't support this.
Advantage of online validations
You always rely on authorization server to verify the token validity.
Disadvantage of online validations
You create more traffic for authorization server. Also your application server require one more API calls.
Regardless you always need public key of authorization server.
I'm building a native Mobile App that connects to a REST API.
I'm looking at this demo oAuth App to use as a guide for my Authentication/Authorisation layer.
When the user comes to the App for the first time I want to provide them with a username and password box.
After they hit submit I want to the App to be supplied with an access token, and a list of permissions (scopes?) that the user is permitted to perform.
I've read lots about the oAuth2 specification but am confused as to which flow to use.
I can't use the Resource Owner Password Credentials Grant because I can't trust the Native App with the Client Secret.
I don't want to use the Implicit Grant, as I don't want to present the user with a "Do you authorise this App?" web window.
I've looked into the JWT Bearer flow, and think it might be what I need as it doesn't require the Client ID/Secret. However I can't find any examples where this flow returns permissions (scopes?) that the user can perform.
Edit #1:
I am confused as to the use of Scope. The specification says-
The authorization server MAY fully or partially ignore the scope
requested by the client, based on the authorization server policy or
the resource owner's instructions. If the issued access token scope
is different from the one requested by the client, the authorization
server MUST include the "scope" response parameter to inform the
client of the actual scope granted.
If the client omits the scope parameter when requesting
authorization, the authorization server MUST either process the
request using a pre-defined default value or fail the request
indicating an invalid scope. The authorization server SHOULD
document its scope requirements and default value (if defined).
From that can my Client request a list of ALL Scopes, and then the Authorization Server give a Response with the ones the User actually has?
Thanks for your help, Tom.
You list two assumptions about OAuth 2.0 flows that are not true:
the Resource Owner Password Credentials Grant can be used with a public client i.e. a native app that doesn't have a client secret
usage of the Implicit Grant does does not imply that it requires explicit consent; that is to the discretion of the Authorization Server implementation; in an enterprise setting or a setting where the same party controls the client and the Authorization Server, that may be omitted
But since the Implicit grant comes with security considerations, for native apps it is typically better to use the Authorization Code grant.
Scopes are a way for the Client to request certain permissions. The Resource Owner can grant the Client permissions that relate to these scopes (explicitly or implicitly). Since the Client will change its behaviour based on what permissions it gets, it is assumed that there's some shared understanding between Client, Resource Server and Authorization Server about what Scopes related to. There's no predefined semantics in the OAuth 2.0 specification, it is up to the implementation.
Assume we have an OAuth2 implementation that supports "read" and "write" scope.
I retrieve an access token "f482c829" with "read" scope. If I then change my mind and now want read+write permission and authorize again with "read" and "write" scope do you:
Update scopes for existing access token and return same token "f482c829"?
If using same token, require that the access token is reclaimed if using response_type=code before updating scopes? (I think yes)
Update scopes for existing access token and return a refreshed token "zf382nL"?
Create an entirely new token leaving "f482c829" and its scopes intact?
If you create a new token every time per scope, you end up having to store multiple access tokens per authorization and different permissions everywhere. I've been hesitant to implement it that way.
The OAuth2 spec (as of draft-12) unfortunately does not address any of this.
In facebook's case, resource server is basically same with authorization server.
So they do "use existing token" way.
And it enable to allow users to disable each scopes on facebook.com site.
About refresh token, you don't need to establish new refresh token. (Of course you can do it though.)
Existing refresh token will also be connected with all scopes.
In Google's case (maybe Yahoo! too), resource server is totally different from authorization server.
Many resource server (Docs, Buzz etc) accept access tokens established single authorization server.
In this case, "establish new token" way seems better.
In Twitter's case (maybe your case too), both seems OK.
Plus, in any way, when user revoked client access you need to revoke all tokens for the client.
User is not revoking "token" but "client".
Since developer should pre-register redirect_uri, using same client credentials both on website and on mobile all seems tricky.
So I recommend asking developers to use different client credentials in that case.
Say one client (mobile) of an application needs read-only access and another client (website) needs to write as well. This would require client to be able to decide the scope of token request and hence provider to store multiple tokens with different scopes.
However, it is up to you if you want to extend the scope of an existing token. This means you can keep one scope per application. This can also make easy to revoke access of an application by a user.