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.
Related
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.
We have a problem consenting permissions and obtaining access tokens to call MSGraph API. Our product is like follows:
We have an API that works with MSGraph. Until now, we have been using Aplication permissions to access resources as mail and calendar.
We would like to start using Task To-Do API and it only supports Delegated permissions.
Our API works with multiple tenant and multiple users in each tenant.
We use admin consent to give all necesary permissions and generate a token aftewards to make requests to MSGraph (Aplication permissions endpoints). With these new changes, is there a way to generate a token valid for To-Do API directly from an administrator, or is mandatory that each user signs in to create a personal auth token valid for this API? We would like to avoid the proccess of user sign in as our API is meant to work behind another application we do not develop after administrator has given consent.
Thank you in advance
In your case, you are using client credentials flow and with that you can not have signed in user or delegated permissions as MS Graph Todo APIs only support delegated permissions.
For you to use the To-Do Graph APIs, you have to can incorporate user signin. If this not possible in your scenario, then you can upvote this feature request - Allow Graph API calls to work with both todo tasks and plannerTasks using application permissions
I've implemented the oauth2-server which is awesome (but sometimes unclear) library. The problem is however, separate from oauth clients I also have users who just need to login. Do they do this with another grant then the authorization_code? If so which one?
Currently I'm doing this via my one-page application via a http POST request with username and password. Should i use the password grant for this? If so do I need to create an oauth client for my front-end application? (this just seems weird)
Basically, the oAuth authorization server supports 2 endpoints according to the spec: /authorize and /token. But if you need another capability, which is totally not related to the oAuth flow, you can add another API for that.
All other grants that you mentioned are related to different flows. The login support is not one of them.
So what I would do is add another HTTP API to support a simple login. This API get user and password (depends how you implemented your DB access - I assume that the passwords are stored in your DB encrypted, to your API should get an encrypted API as well, etc...)
BTW i have this GitHub repo https://github.com/OhadR/RESTful-login with a sample code how to perform (and use) restful login
Scenario
We are building a new RESTful API for our web application. This API will serve our mobile applications, our web application and authorised customers.
We are using Apigility to build the API and are making use of the OAuth2 implementation it provides.
Currently, our web application relies on a users table, with permissions assigned to each user. These users simply log-in using a web form, and the session is then stored and appropriate permissions checked upon access.
We want to be able to authenticate API access (such as our web app, and authorised customers), so no unauthorised access to the API can happen. However, we also want to authorize the permissions at a user level, therefore some sort of user authentication must also happen as well.
Any authorised access to the API may use a different user, so relying on a single user per client will not work, especially since the permissions are on a per user basis. We also do not want any user to be able to use the API without prior authentication, so wanted to avoid adding every user as a client to OAuth2.
For example:
The web app is authenticated with the API with two users using it:
UserA has user management permissions
UserB does not have user management permissions
Therefore, UserA can POST to /users and receive a 200 OK while UserB should receive a 403 Forbidden.
What we have tried
We have created an example application, and have successfully set up authentication using OAuth2 for the high-level clients and can make calls as expected. But we have not been able to create an authorization model for our users based on this.
We though adding a custom HTTP header with a user token that is provided after an authenticated call to /user/login. But we are not sure if this is the correct method.
The question
How can we both authenticate the high-level clients (such as our web app, or authorised customers) but then authorize access based on the user actually using the system?
You have a few options available to you:
Token-level permissions
You can provide different tokens for each user account, and tie permissions to the token. This runs the risk of the wrong tokens being mixed up with the wrong users. However, this also has the advantage of not having to maintain a user<->token relationship, as the permission is decided at the token level. How you decide which token to generate can be tricky.
User-level permissions
You can tie a user account to a token and that user can then be given read/write permissions. This reduces the risk of a user having a wrong token as they're linked. With this method, you can use the same method of token generation for all user accounts as the token is ignorant of the permission, but does allow them "access" to the API (thus preventing unauthorised access).
I've deliberately avoided mentioning specific types of authentication tokens, as these two concepts can apply to most of the popular choices on the web (token-based, OAuth based).
OAuth has no concept of Identity.
You should look into using OpenID Connect which is a profile on top of Oauth 2.0.
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.