I am working on some project in spring boot in which Oauth 2.0 is implemented which have grant type as password. I want to change it to "implicit" auth grant. But I have read in one of the article that, it is not safe to use this strategy, as it use token along with URL.
So should I change it to "implicit" or look for any other grant type.
This is the link of above mentioned article.
https://medium.com/oauth-2/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926
You should not use implicit grant type as it is also not recommended by OAUTH.
Please refer draft link of security best practices provided by OAuth which shows problems with implicit.
Related
Currently our spring boot app uses okta for login. There is a need to implement RBAC for the application so I was trying to see if I can leverage okta itself for mapping users to specific roles.
I would like to implement the standard RBAC model in which I would map multiple permissions under a role and the roles are associated to users. Basically it involves 3 levels permissions > roles > users.
But in okta I don't see the standard way for mapping roles and permissions. RBAC is achieved by creating groups and associating groups to the users, which is two levels. And groups needs to be added as a custom claim.
How do I achieve the standard RBAC mapping(permissions > roles > users) in okta or it's something that needs to handled outside the IDP provider.
Thanks in advance.
Possible Solution:
You can make the scopes (scp in access token) be your permissions. Below are the steps:
In your Authorization Server, create your custom scopes(permissions) and set them as default scopes (this is necessary).
For example create 2 default scopes:
books.read (default=true)
books.write (default=true)
Go to access policies in your Authorization Server create one if none is defined.
Create access policy rules in the access policies page, the rules will be your mapping between groups and scopes.
Test that in Token Preview tab, the trick here is to leave scopes field empty so that the Authorization server can return the default scopes that are set for the user, as explained by Okta:
A default scope will be returned in an access token when the client omits the scope parameter in a token request, provided this scope is allowed as part of the access policy rule.
Now in your application when requesting an authorization code make sure that scope query param is empty.
Depending on the library you are using you may face some issues if by default they are expecting an id_token to be always returned but you will probably be able to customize it. For example: https://github.com/okta/okta-auth-js/issues/827
Solution Limitations:
As mentioned in steps 4 and 5 we are omitting the scope query parameter, this mean that only our custom scopes assigned for the user or his groups will be returned, since the base scopes that are predefined by Okta such as profile, openid, email ... will not be returned. Which also means that we are skipping OIDC which needs the openid scope, so id_token will not be returned and only an access_token will. So this solution assumes that you don't need any of the base scopes predefined by Okta.
In case you need any of the base scopes
As described in the limitations, the solution assumes that you don't need any of the base scopes predefined by Okta. But in case you do then below is a solution that works in that case but not that nice.
When requesting an authorization code in the oauth flow, you need to send the request twice
first one: omit scope query param, so the default scopes are returned.
second one: append the returned scopes returned from the first request to the list of base scopes you wanted such as openid, profile, 'email`. So you would send something like (encoded already)
?scope=books.read%20books.write%20openid%20profile%20email
Disclaimer:
The above solution may not be recommended, but it works. If anyone can find any security issues with the above solution please leave it in the comments.
When you get into the details of roles and permissions, the data tends to be domain specific and to change often. I would advise against trying to manage it in the Authorization Server.
One design pattern that will give you full control over claims is to form a custom AuthenticationPrincipal that includes roles or permissions from your application database(s).
If interested in this pattern, see these resources of mine:
Custom Claims Blog Post
Java Custom Claims Code
How to run Java Code Sample
the samples for msal.js are still using implicit Grant Flow which seems to be vulnerable and shouldn't be used anymore according to this document from IETF.
My question is: Is it possible to use the code Grant Flow using the msal.js, and if yes, does someone maybe have a sample of how to implement it?
Please check this code sample. It shows how to implement authorization code flow with SPA:
https://github.com/Azure-Samples/ms-identity-javascript-v2
Hallo i am new to oAuth and i created a rest connection to Magento with that example
http://devdocs.magento.com/guides/m1x/api/rest/introduction.html
the php script is working and i can connect to magento. But i have to enter the admin credentials and after that i have to click the Authorize button.
now my "magento rest project" is triggered by a database. so i was searching the last hours how do i get the accesstoken without really clicking on the button? is there something like that for cli or is it even possible?
thank you very much for helping me to understand it.
cheers pat
It would be possible if they supported the client credential grant, or kind of possible if they supported refresh tokens. Unfortunately, they don't support either.
For the authorization code grant that you are implementing, an authorization decision is made by asking the user if they are willing to allow your client to access their data (to protect the user's privacy). This is mentioned in the Magento docs as well.
The built in Magento REST Api functionality doesn't support grant types other than authorization code grant.
I managed to use a customized oAuth2 library (https://bshaffer.github.io) (customizing the class so that it's compatible with the Zend Framework that magento is based on). It will let you choose your own grant type (in your case, Client Credential Grant).
The downside is that I had to re-create all the REST API endpoints. The upside is that it's not that hard, at least not harder than creating a custom endpoint using Magento's built in REST API functionality.
I'm fairly new to Oauth2 and it seems I'm stuck.
To protect our API, we use OAuth2. We have a lot of calls that contain information based on an account, se we use the password grant in OAuth.
But, I also have to protect my registration call, so only registered applications with valid client_id and client_secret can use that call. So, after reading a while, it seemed that I needed to use the client_credentials grant for those calls.
But now, I have absolutely no idea how I can define witch call should be using password of client_credentials.
Am I thinking wrong and is it impossible to use a specific grant for a specific call, or how can I define when to use what grant?
FYI: I'm using Laravel5.1 and Luca Degasperi's Laravel OAuth2 server
Thanks!
Usually you won't limit calls or routes to specific grant types and for several reasons it's nearly impossible to limit the client-application access via oauth grants.
So as a rule of thumb you should only expose the endpoints the user is allowed to access doesen't matter which client is used.
Further more I would prefer the client credentials or owner credentials grant, it's better in facts of usability and security (Change Password, Remove Access for specific apps, ...) more about the different grants.
How i can make a request with implicit grant type ?. i have googled it and couldn't found any example for it.
All i want is to use implicit grant type in my HTML5 app but i am not sure how i can configure it , i am able to use other grant types.
Thanks