We're using oauth access token for a mobile app to communicate with our backend.
The simplified steps are:
User input PIN
FE send request to /oauth/token
/oauth/token verify pin and check 2 additional legal consent flags from legacies
/oauth/token cached the flags
/oauth/token return access token
FE check flag 1 and show 1st consent screen if the user hasn't accepted the 1st consent before
FE check flag 2 and show 2nd consent screen ''
The question is:
Is adding additional logic to check for 2 flags in /oauth/token consider a good practice or not?
Should we separate the logic to check for legal flags to another API calls from FE to make the /oauth/token more lean and maintainable?
I've tried to read through the Oauth standard and other practices but could not find any related to this.
OAuth 2.0 is a protocol with a specific set of rules and its own terminology. If you wish to implement a solution that follows these rules, then I suggest that you have a look at "Authorization Code Flow with Proof Key for Code Exchange (PKCE)". For more help, see https://auth0.com/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use
To your question: You can add your own parameters to the flow as long as you provide the required parameters specified by OAuth 2.0.
Related
My question is related to this blog post:
https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc
In step 5, the authorization server returns an authorization code to the client:
Right after that in step 6 the client returns this authorization code back to the server, together with Client ID and Client secret, and receives the access token. Whats the purpose of this "Authorization Code round trip"?
I believe you are asking “why not just return the access token directly rather than first getting an authorization grant and then trading it for the access token?” The answer is because that would be insecure.
The authorization grant is returned in a query parameter of the redirection URI. Putting sensitive values in a query parameter is a no-no: these values get logged in web browsers and web server logs. The Oauth protocol works around this security no-no by using an authorization grant that is one-time use. Once that authorization grant is exchanged for an access token, that grant is no longer valid and cannot be re-used. Hence, the fact that it is logged means that it doesn’t matter : by the time it is logged, it is no longer valid. On the other hand, the access token is for multiple uses, and therefore cannot be logged — which implies that it is not safe to put in the query parameter.
That’s the entire reason why they introduce the authorization grant extra layer of complexity. If a server allows the authorization grant to be used multiple times, that would be a security bug (it is prohibited in the Oauth protocol).
That’s an excellent blog on Oauth, BTW. One of my favourites.
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.
As I am planning to have OAuth or OWIN JWT Bearer token for my authentication, I have following requirements for which I dont know the solution or grant type to suggest. I would appreciate a small example code especially how a payload will look like and claims will look like AND the Grant Type I should have for this below:
I have angular 8 UI which asks for Username/password (Azure AD Authenticated)
User logs in, then should have facility to copy paste the URL (In session) to another tab or new browser.
User when working (Its a call center case manager and so uses session for long time), the token shouldn't expire while he/she works. I studied that token will expire on time we set and no way to control this. Now, unless we have "Refresh" token, we can't achieve this, i.e user should have seamless experience to continue task even if token expires as refresh token should be used (Or whatever the mechanism).
If I use refresh token, then only authorization code grant type is possible where userID/password not safer. If I choose "Impliit" grant type, no refresh tokens available in this.
I am not sure how to achieve all points above. Please guide
In case of implicit grant flow , the SPA has to send a request in hidden iframe to get the token refreshed. Base on valid browser session the application request for refreshed token access.
For Azure AD, You should be using microsoft-authentication-library-for-js , and this library provide this feature out of box using acquireTokenSilent method.
I would highly recommend going through implicit grant flow document and you will get very good understanding. Implicit Grant Flow
I am not sure you can find complete example but i can give you few links with code samples and all of them would make up complete example. Also i can't see any Angular 8 Library , the given library is for Angular 6,7 but probably same can be used for Angular 8 as well.
For Angular you might have to use this library microsoft-adal-angular , and Example How to use microsoft-adal-angular
In the given link you can find how to refresh the token as above example is missing that part. Refresh Token Code
I'm trying to implement Two Factor Authentication (2FA) in a Web API 2 solution using OAuth 2 and Bearer Token with the help of OWIN. I know 2FA with Bearer Token is not a standard workflow but has anybody successfully done this?
Basically, I have two scenarios I need to cater for:
User credentials are correct and no 2FA is required so return full authorized Token. This I have done and works correctly and works with methods in Web API controller that has the [Authorize] attribute on.
User credentials are correct but 2FA is required so I want to return a valid Token that does not give them full access, so methods in Web API controller with [Authorize] attribute do not allow access.
Once the security code has been successfully entered I want to then generate a new full-blown bearer token as in scenario 1 above and return that, giving full authorized access.
I'm using Identity 2 to create the secure code and email the code, which works fine but the area I'm struggling with is in the overridden GrantResourceOwnerCredentials method to cater for the two scenarios above. Any information or code examples would be appreciated.
I am creating an API for a mobile application using Rails 5. At the moment, I don't need three-legged authorization, as the API will only be consumed by our own mobile apps.
I'm thinking of choosing one of these two options:
Doorkeeper + Devise: I can implement OAuth 2.0 using Doorkeeper, but I will only be using the Password Credentials Grant, at least for now.
Rails' own ActionController::HttpAuthentication::Token module + Devise: This seems like the simpler way to go.
Honestly, I can't see the difference between the Token Access Authentication method and OAuth 2.0's Password Credentials Grant.
How would one choose one over the other? Is there any other option that needs to be considered?
If all you'll ever have is the "single purpose API" (only for mobile application), there is no big difference in terms of security.
But if you'd like to extend this API to be used by the external services, then, you'll be in a much better position with implemented OAuth 2.0 using Doorkeeper, because you can easily configure, for example, a Authorization Code Grant for them.
So, I'd say that "Doorkeeper + Devise" option is more future-proof, because it provides more options, while HTTP Token authentication is much simpler for implementation.
The two are conceptually different things:
"Token Access Authentication" specifies a protocol describing how a (possibly long-lived) token should be presented to the server securely. It says nothing about where the token came from or how it should be interpreted.
"Password Credentials Grant" is a part of the fully-fledged OAuth flow, describing the means of obtaining a (usually short-lived) token.
In a sense, you could use Password Credentials Grant to obtain a token using OAuth and then use this token in the Token authorization header to gain access.
The question then becomes - is it useful to do the extra roundtrip for exchanging the (permanent and secret) credentials for a (temporary) token, when we could instead use the (permanent and secret) token stored in the app to authorize immediately anyway.
As I see it, there are two potential benefits of using the full OAuth flow. Firstly, it lets you add other means of authorization for third parties naturally. Secondly, it lets you revoke the token at any moment and force a re-authorization using these other means (if you implement them, of course) without having to invent any wheels.
On the other hand, you can always add any additional "token generation" parts later, when they are needed. Thus, if your current plan is to hard-code credentials in code anyway, I'd suspect you are probably better off relying on Token authorization.
Not only is it one request shorter, it may also be slightly more secure than the Bearer authentication used in OAuth: if an attacker sniffs a Bearer token, they would (usually) get full token access to the server until its expiration. It is not the case with Token tokens (normally). Not that it all matters too much of course if the attacker could extract the shared secret from your app anyway.