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.
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.
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
I have been doing a lot of research into how to authenticate mobile apps with an API - I still feel a bit unsure about which flow & architecture would be better to use in my particular use case.
I think what's confusing me is some of the terminology used.
My use case:
An API & database on one server. Which holds the users & and the users resources.
A web app, which I have built and consumes the API. Hosted on the same server as the API. So it's dogfooding.
A web app, which I have built and consumes the API. Hosted on a different server to the API.
A mobile app, which I have built and consumes the API.
I'd like to be able to authenticate with the API using username & password.
The API will never be opened up for consumption by other 3rd party services except the web app and the mobile app.
Initially I felt like using the Resource Owner Password Credentials Grant flow would be sufficient. However in the docs it states that this flow should be used if "The client is absolutely trusted with the user credentials".
Since both my mobile & web apps will be built by me, I'm assuming they are seen as 1st party clients. Therefore am I right in thinking they are considered to be trusted with the user credentials? As I typically thought that when implementing oAuth, the idea would be to have the authentication server separate from the resource server. Which would allow you to have one authentication server for multiple APIs.
After reading this post: Why the Password Grant is not suitable for modern applications
It threw me off track a bit. But then, is this post talking about using this flow in my use case?
I was also looking at the Implicit Grant Tokens flow. However using this flow I couldn't really see how the user would enter their credentials first?
I also question if any of the oAuth flows is really needed for my use case and I should instead look at other ways of authenticating?
I'm really quite lost with this I would like some direction to go in with how to authenticate users in my particular case.
Thanks in advance!
I'll most likely be using Laravel to house my API and so I do have Passport available to me to implement oAuth
EDIT
From following this oauth article I've found that in all use cases of my app, I end at Password Credentials Grant flow. Would I be correct here?
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.
I'm developing an application where Google Drive will be used to manage some documents. The idea is to create a document with some initial template data and provide the users access by adding them as collaborators of the document.
I'm familiar with the OAuth authentication process, I used it in another part of the system to manage the users Calendar...
But in this case these documents will be stored in a generic account of the company, so I can't have the approval prompt for authentication, since users won't have the password of the account.
I'd like to directly authenticate in this account, could be with the username and password hardcoded in the Java code.
Problem that this method of authentication was depreacated and I didn't found a relpacement.
Any ideas?
Thanks in advance,
Phillip
There are 2 ways that comes to mind:
Service accounts: best suited for server side OAuth with traditional backend
Regular Account owned by the application : similar to the process already in place for client side Oauth that you are already familiar with; Auth, store the refresh, ask new token if the AuthCode is expired, and so on.
I personally use and prefer the second solution more as I feel is more flexible to adapt in the future for Oauth Client Side get the tokens and use them server side.