When authenticating with a JWT should custom scope(permissions/claims) go in access token or id token? Seen it done both ways but not sure what is best practice.
I work with the Auth0 Community team and wanted to reach out. You can build out scopes using Auth0 when an app requests permission to access a resource through an authorization server, it uses the scope parameter to specify what access it needs, and the authorization server uses the scope parameter to respond with the access that was actually granted (if the granted access was different from what was requested). From what I am reading it sounds like using scopes and claims might be the direct goal here when working with a specific user. I hope this helps you on your path but if you have any questions please let me know!
Related
I am writing a REST API and I want to authenticate users with Auth0. I also wanted the users to be able to get a list of all the users registered in the tenant (just basic information, maybe even just username) and I saw that there is Management API for this.
I'm a bit confused about how to grant read access to the Management API to all the users, but I thought about a couple of possibilities:
grant read access to each single user
expose endpoints in my API to proxy requests towards Management API, so that I can use client credentials grant
use a post login action that adds basic user information to my private database (I don't like this, I'm foreshadowing sync issues)
Which one should I use (or maybe a further one)? I'd also appreciate basic guidance on the solution that you suggest. Thanks!
You should not need to grant your users access to your management api. Instead you should use your client credentials to get an auth token to use for this. In fact, the Auth0 docs have recommendations about how to use the management api in your application.
If you wanted to add user authorization on the routes that use the management, you can simply verify tokens and user roles as you do on other routes of your API. But you (typically) shouldn't use the user tokens as your tokens to access the management api.
gapi.oauth2 is being deprecated so I'm trying to set up Google Sign In using the new GIS Client. However I'm having a serious issue when the user grants access to scopes. The checkbox for one of the scopes is unchecked by default. Users often forget to check this and then our app just won't work for them. With gapi I could handle this by requesting additional permissions if they forgot to check the box. But the new GIS Client has no such functionality. Any ideas on how I might solve this problem? Thanks so much.
Normally, in an OAuth flow, in such a case you would make a new authorization request with the complete list of scopes that you need. The authorization server should be able to tell that you are asking for more scopes than the user previously consented to and ask for a new consent. It seems that GIS Client is using a standard OAuth flow, so I would try to solve your problem this way.
I have to integrate Keycloak with an already existing C++ App, made up of several microservices. The database that is being used is MongoDB. Worth mentioning is that this app is a Desktop Client and will continue to be that way. I find Keycloak docs not that straightforward and would like some help on how to implement the security of the app to be delegated to Keycloak.
Saving the users and Keycloak data in MongoDB would be a nice feature. But as far as I know, that is not supported anymore, so I used PostgreSQL as a Keycloak specific DB.
From my research, I have found out that if I want to receive an Access Token without a browser, I have to use the Direct Grant feature in Keycloak. So making a POST request to
http://localhost:8080/auth/realms/my_realm/protocol/openid-connect/token
with my data (client_id, client_secret, username, password, grant_type=password) would supply me (the app) with an access token and a bunch of other data. The question is, is this the right way? If not, what should I do?
What about user registration?
What am I supposed to do with the access Token, my data is in my MongoDB?
Can you direct me to some plain-english tutorial/docs for keycloak?
Thank you.
After having read books and watched videos on OAuth, OIDC, PKCE, JWT, etc. I still have no idea on how to use all of these for my app (a secured REST API).
My use case is fairly simple. I want my users to be able to login with Google, Amazon, Okta or whatever and the only info I want from them is the email address they used to login, nothing else. After their first login, their email will be added to a database and in a separate process I will grant them some permissions (what resources they can access).
So let's imagine a standard authorization code flow and let's fast forward to the access token part. The redirect URI has been called, we are in my client (somewhere is my backend/API) where I retrieve an access token. At this point the user has been successfully authenticated.
But what now ?
I don't care about Google anymore (do I still need the access token ?), but I still want to check if the user can use my API for each request and is able to access the API resources depending on his permissions.
How do I keep the user authenticated (for like 2h only) and check his permissions ? A session Cookie, a Token or something else with an expiration time ?
Do I need my own authorization server to check if the user has access to the resource he is requesting ?
Considering my requirements, do I need PKCE if the API is accessed from an SPA or a mobile app ? Wouldn't the authorization code flow be enough - the SPA or mobile app retrieve an authorization code, then call the callback endpoint from the API ?
And the more important question is, do I ask the right questions or am I completely off track and it's not how it's supposed to work ?
In terms of your questions:
Your API needs an access token on every request
A stateless session is managed by sending the access token on every request
It is recommended to use your own Authorization Server that manages redirecting to social providers - this will simplify your UIs and APIs which only need to handle one type of token - also this means you are in control of the tokens your apps use
Yes - use PKCE for public clients - the Authorization Server and UI security libraries will handle this for you
Your use case is not simple at all on a technical level and requires a lot of understanding. A good starting point is to understand these aspects:
Role of UI and what a coded solution looks like
Role of Authorization Server and its configuration
Role of API and what a coded solution looks like
Open Id Connect messages used
These links of mine may be useful for browsing:
Initial code sample and tutorial
Message Workflow including PKCE
Given an access token, both the UI and API can potentially get the email via step 12 in the second link to lookup user info.
I am creating a REST inspired API for a Learning Management System. It will expose data such as users, classes, grades, courses etc. I have defined all the resources I want to expose, given them each an endpoint URL, and defined the JSON resource structures that are returned.
I now want to understand how to secure the API using Oauth2 (I don't want to use Oauth1). Am I correct in the assumption that my API will play the part of both the Authorization Server & the Resource Server? Also, what grant type / flow should I be researching?
A lot of the tutorials seem to focus on using Oauth2 to login using facebook credentials etc - but I just want to use it to secure my API and allow my users access to my API (either through a client, or directly). The access permissions for the API should follow the individual users access permissions that are already handled within our system.
Sorry for the scatter-gun questions - I just don't understand oauth2 enough to know where to direct my research. Any help would be greatly appreciated, and any pointers to simple tutorials for the correct use case would be great too.
FYI - The system is built on a LAMP stack using Drupal 6 (old, I know).
Well your assumption is correct the authorization server and the resource server can be on the same server or in the same API.
So how the OAuth2 basically works you have some kind of client(Server, Browser) Authorization API will authorize with Access Token to use your resource API which is then sent in the the Authorization HTTP header on every resource request.
So what I success is that when the user logs in, you identify the user and generate the Access Token immediately to the client. Now you can put some data inside the Access Token e.g. userId, permissions etc. Now when the Access Token hits your resource endpoint you can identify the user and check the permissions. Also you can just make the Access Token dumb so it doesn't contain any data then when you validate it from Authorization API(on Access Token creation you have to store info about the user to Authorization DB), you can get the info you need on the response e.g. userId, permissions etc.
What grant type flow to use, this is basically up to question what kind of clients are using your Authorization API and how secure you want the Authorization to be. E.g. implicit grant is for browser based clients which can handle redirections and e.g. Client Credentials grant is for (server-to-server) communication.
Reference here
To start with, you can use existing providers like WSO2 API Manager for supporting your system. It is well documented and has many REST APIs for this.