I find keycloak restful authentication api in postman，like this:
I know this api will return keycloak token if I give correct username and password. But now, I want to custom a api to let keycloak to finish authenticate like this, then I can obtain a keycloak token.
I read keycloak doc, but I think authentication spi can't achieve.
Is there a way to achieve this?
Adding a new API (rest endpoint) to Keycloak is possible, but you should not (and probably can not) use it to add such a custom authentication. Keycloak as an identity provider is OAuth/OIDC Connect compliant and the endpoints to get/exchange a token are all part of those specifications. So if you want to protect your API using a token provided by Keycloak, you should follow the steps specified on those specs. I suggest you to read a couple of OAuth/OpenID Connect tutorials on the Internet or have a look at a post like this. You should first decided what OAuth flow matches your use-case. Then you can go to the Keycloak console and configure clients for your applications. I guess probably you would need one for the caller and one for the service that is going to be called so that they could authenticate themselves to Keycloak. I don't think that for your scenario, you would need any customization on Keycloak.
Related
I want to develop an authentication mechanism for 3rd party applications using keycloak initial access tokens. But I want to do this only by using the access tokens that I have generated in the keycloak. For example, I will give a generated token to the user and allow him to log into the application. Is this possible? How can i do that?
Initial Access Token
First, I'm not sure it is a good idea to use "initial access token" for authorizing requests to your own resources. It might even not be allowed. As per the doc:
An initial access token can only be used to create clients
Second, don't use keycloak libs for Spring as suggested in other answer. It is very deprecated.
Last, a REST API secured with Oauth2 is a resource-server (and not a client). As so, the dependency should be spring-boot-starter-oauth2-resource-server. Spring doc is pretty extensive on the subject. You can also have a look at those tutorials for resource-server configuration (and OAuth2 definitions).
Once the resource-server (Spring REST API) is configured, clients will have to authorize their requests as normal for OAuth2: provide with an Authorization header containing a Bearer access-token (a JWT issued by Keycloak to the client with one of standard flows: client-credentials or authorization-code depending you need to authorize the client itself or a user behind it).
Edit
I might have misunderstood your need. If what you want is having new clients register themself programmatically on your Keycloak instance, then those clients will just issue a REST request to Keycloak server API with the "initial access token" in Authorization header as normal.
Once registered, those clients will be able to call you resource-servers as described in my initial answer.
I have two web applications app.domain1.com which is a SPA with his own API on api.domain1.com and app.domain2.com) with each have their own authentication system and user accounts
and I need to authenticate the user from app.domain1.com from app.domain2.com. The goal is to simplify switching from one app to another without requiring the user to log into each application by re-entering their password. I'm the owner of one app only so It's not possible to put them behind a reverse proxy or so.
Example :
app.domain2.com redirect to app.domain1.com/connect/{JWT} -> app.domain1.com SPA extract the JWT and send it via ajax to api.domain1.com for validation and login.
I have looking for OAuth2 and OpenID Connect for these but OAuth2 is more about delegation of resource access than authentication and OpenID Connect needs an Identity Provider which seems incompatible with my use case where each app has his own authentication mecanism and where I could not add a central authentication server.
Ideally, I'd like to adhere to a standard protocol.
I thought I could expose an endpoint GET /connect/{JWT} on each app.
The JWT could contains an email which could identify the user account, app.domain1.com and app.domain2.com could then share the secret for validating the JWT has not be tampered
and could have a short validity duration.
This endpoint validate the JWT, verify if a user match the email inside the JWT and log the user in.
I'm not sure about the security considerations with these process and if there is any other options ?
Thx for your help.
In my opinion you should go with OIDC. That protocol is designed exactly for the feature you described here. You can have one of the apps act as the IdP, and the other will be a Relying Party. It depends on which technology you use for your apps, but in some languages there are libraries which will turn your app into an IdP.
You can think of some generic protocol to make that federated login work, but you will be better off using standards. This way you won't have to wonder what are the security implications for your solution - you have security considerations for OIDC described in the spec itself.
I have several REST APIs which I want to secure with a federated authorization server. This page: https://oauth.net/articles/authentication/ suggests that OAuth2 alone is not enough for authentication and one should use the OpenId Connect extension to get it right.
However, I have the feeling that what OIDC does is only defining an identity endpoint and the related scopes and claims. If I don't specifically need these identity claims, what's wrong with using plain OAuth authorization code for authenticating a user and protecting resource? Or is OAuth2 only for delegating access to a client app which works on behalf of the user (which is not my use cas)?
Thanks for the inputs!
Most end user authentication related work occurs on the UI side of things, and of course involves Authorization Redirects, Identity Providers, Consent Forms and so on.
In terms of the code for a Secured REST API you instead perform the following types of action. This is primarily OAuth 2.0 behaviour as you say, though Open Id Connect endpoints can be useful:
Validate received access tokens from the Authorization Server
Read token claims to identify the authenticated user
To do this you may need to download token signing keys from the JWKS endpoint
Your API can look up further details from the User Info endpoint
Your API can use the metadata endpoint to get the above endpoint locations
Your API will then apply authorization rules based on claims and scopes
OAuth is an authorization framework. Before OpenID Connect, some organizations were increasingly using OAuth as an authentication mechanism just as you stated in your question. While this is technically possible, it is rife with inconsistencies between one implementation to the next. The standardization of this method came around with OpenID Connect, where this group of vendors essentially said let's come up with a standardized approach to what we have been doing. The benefits of a standardized approach is collaboration, security, etc. The openid scope of OAuth was born.
Currently, I'm working on a REST API which will be available for public clients but also I wanted to use it in my mobile application.
For the public clients, I considered to use the Clients Credentials grant, in this case, they would have to registered their app in my Web application which will give them the client key and client secret, then, they could request the access token with them and also I could know the user related to the credentials
But with my mobile application, I'll need to have a sign in section where I would need to use Authorization Code grant in order to secure my data, but I'm not sure if it's necessary.
Based on this, I have a couple of questions:
1. The Authorization Code grant it's the best way to do it?
2. It's a bad practice to have two authorization flows in the same endpoint?
3. Dropbox, Twitter, etc...all of them have REST API, how do they manage authorization in their own apps?
Thanks beforehand and sorry for all questions
I managed to solve this with two alternatives and for the moment, I'm going with the first one.
Create an Authorization server with a parameter that indicates what kind of Authorization Grant it's asking to use and in this way I can decide which kind of flow will follow based on this. I follow the OAuth 2.0 Spec for this using the correct names and parameters to pass in order to have a good way to authenticate our clients and applications.
Create an API gateway where I can send all the authentication requests for my API's using Node.js and in there it will be decided which API it's asking for authentication and with kind of Authorization Grant it's using. You can have more information about this in here:
https://www.nginx.com/blog/building-microservices-using-an-api-gateway/
I'm gonna try to explain my problem :
I'd like to allow users to connect to my api via their own accounts (login/password) or via a social network (Facebook at first).
Then, I would allow any application to use my api, with the user authenticated.
My first thought when to auth the user via his/her login/password and return a token used as the session for the next requests.
But OAuth would seems to be the better implementations, except I don't know how to do this :
One of my applications will have to connect via login/password, like twitter web (I have to implement an login/password auth somewhere if I wan't my user to login :p)
Will I also have to register my applications to the oauth system (did twitter added their web app to their oauth ?)
How to merge the auth via others social networks. Concretely, the user will have to OAuth to my api that will auth to the social network.
I'm a bit lost on how to do this, if someone could help me, I would really appreciate !
Thanks
Update 1:
Flickr and Lastfm seems to not use OAuth but an alternative auth system that looks like this :
The user is redirected to Flickr/Lastfm
The user auth himself and accept to use the application
Flickr/Lastfm return to the Callback url with a temporary frob (for flickr) or token (for lastfm)
The app must call the provider with the temporary frob/token (among with the api_key and the api_sig, as always) and get in return the session token to use for the next calls.
Update 2:
In fact, StackApps is the concrete case of my problem : you can login through their login/password system OR openId, and you can use their API.
OAuth is only needed to make others use your API on other services, i.e. authorize services to use your API without users of the intermediary service explicitly having to log in into your service by giving user's login credentials to a third party.
What I think you need is OpenID, the cross-application authentication mechanism. You just need to implement an OpenID client, accepting third-party OpenIDs to authenticate users, to subsequently identify them, when they use your service's API. This would have to be supplemented with a normal 'local' user authentication mechanism (i.e. login/password entry page)
You will need OAuth to provide an ability to use your API on other sites, though.