I have a REST API application which is protected using Keycloak(client) via oauth2-proxy. I also have Azure AD added as a IDP in Keycloak.
My usecase is to receive success(Http -200) to REST API by using Azure AD user access token. Is there a way I can get Azure AD access token validated by Keycloak via REST call and receive access token from Keycloak?
From what I understand from your explanation, the external token to internal token exchange may do the trick for you. Look at this section of the token exchange documentation to see if it does what you want: Securing Applications and Services Guide
These are preview features. Here is what the documentation says about preview features: “Preview features are disabled by default and are not recommended for use in production. These features may change or be removed at a future release.”
However, my own opinion is that you can use them in production, provided that you carefully evaluate every release before upgrading, to make sure that the features are still there and working as you expect them to.
Link to the doc: Enabling and disabling features - Keycloak
You could use Azure AD as your IDP for this application. It is even possible for a single application to support many IDPs, in your case both Keycloak and Azure AD. You may have to write some custom code for that.
Also, if anyone here have a idea of when we can expect admin-fine-grained-authz and token-exchange features to be formally part of Keycloak, I am interested to know.
Browser flow works absolutely fine. However my usecase is only for REST API calls. You mean to say create custom code for REST API call like browser flow, to receive Keycloak access token for a Azure AD user?
For instance, upon receiving a token, your REST API can treat it as either a Keycloak Token or an Azure AD token depending on the issuer claim.
That way, it will support tokens from both IDPs
My two cents here (I haven’t read all the thread in detail):
One thing is authentication, and the other is authorization.
Once you solve authentication, no matter the authentication mechanism—whether it’s identity federation with an external IdP such as Azure, passwordless, etc.—you end up obtaining KC tokens (id_token, access_token, etc.).
Then you move to the authorization part. One option is to use OAuth 2.0, and your APIs will act as OAuth 2.0 resource servers by using Keycloak tokens. Period.
If you want to move to a more complex scenario for some strange reason, meaning that the API/Gateway will support validating different tokens (meaning multiple issuers), it is also possible, but I don’t recommend it.
Generally speaking, it’s true what’s mentioned in the docs about preview features. But no rule without exceptions…
For token exchange, it’s a bit different. Token exchange was implemented in the early days of Keycloak, when the token exchange spec wasn’t finalized. Thus, only parts of the spec are implemented and that’s the reason why it’s “preview”. The token exchange was finalized around 2020 (afair), but since then, nobody was found to implement the token exchange features fully. That’s why it is still on “preview”.
Recently there was a discussion around token exchange, that the team want this to be completed in the future (what ever that means) and is looking also for volunteers… sorry, I don’t remember which discussion/issue this was exactly.
For the admin-fine-grained-stuff… just a very personal note: hopefully this gets implemented completely new (but I doubt that it will actually be the case), because from my experience, it’s crappy implemented and doesn’t work like expected. Ok, at least for token-exchange it works, but…
No, you must not do that!
Not before you have validated the signature!
And to validate the signature, you must not use the data from the payload!
Otherwise it’d be easy for an attacker to inject malicious tokens.
(another episode from the tale: not everything what is technically possible, is also a good idea)
Besides that, everything also what @embesozzi mentioned.
Just thought to simplify my ask with below diagram. @dasniko@embesozzi Can you suggest if Tokenexchange setup is the only way to authentication my Azure AD users to my REST API application or i could use other APIs of keycloak to get KC Token?
Agreed that validation of the signature must be the first step. However, if supporting many IDP is expected, one application can have many IDP configurations and try signature validation in a loop until the right IDP is found.
I do not enter into the discussion on whether or not supporting many IDPs is a good thing or not. I just know that in my job, we had to do it, and it was completely legitimate, and we did it in a secure way.
@dasniko I still facing error below, any pointers please?, does this means that Azure AD user’s info should be available on keycloak? Like how it works in First login in browser flow.
error=invalid_token, reason=‘user info service disabled’, auth_method=token_exchange
Can anyone respond to this post, with exact steps to be followed to make this feature work for Azure IDP users? with the document Securing Applications and Services Guide, I understand that the provider’s(Azure AD) user info service will be invoked by keycloak, so which means any additional configuration to be done on Azure AD side?
I see there are similar post in past , but none has a resolution for it, one examples below
