I have a legacy system that has an existing login mechanism - assume it is a custom method. We have another set of services that require an oauth2 access token and use keycloak for generating and verifying the tokens. After a user logs in we no longer have access to their password hence I can not use the password grant to get them an access token to our oauth based system. What are the recommended approaches to generate this access token. What I have looked into so far:
impersonation (token exchange)
custom keycloak userstore SPI that validates user with blank password
I guess using a client credential flow to generate a token that tries to match the users roles and attributes.
It seems to be a use case that is not well supported by oauth2?
It seems to be a use case that is not well supported by oauth2?
Your use-case seems to match those defined in the OAuth 2.0 Token Exchange specification
One common use case for an STS (as alluded to in the previous section)
is to allow a resource server A to make calls to a backend service C
on behalf of the requesting user B.
For this approach, you will need to configure in the appropriate Keycloak realm your legacy system as Identity Provider. So that you create a trust-relationship between the legacy system and Keycloak. Afterwards, you can exchange the token coming from the legacy system (resulting from the user authentication) for a token of the aforementioned realm. Depending upon your setup you might need protocol mappers that map the legacy system roles to the roles in the Keycloak realm. All of this is assuming that your legacy system is to a certain extend Oauth2 compliant.
Otherwise, another approach is for your legacy system, to call a confidential client on Keycloak and pass along some claims (e.g., the user roles). This is assuming that your legacy system can securely store the client secret. All of this, of course, depends upon the concrete characteristics of your setup.
Related
We have a client that among other things creates and manages Keycloak accounts.
Would it be possible for that client to retrieve tokens on behalf of the users without having to create any user passwords at all? In fact, we'd like to create user accounts and not set a password to start with. None of these users will ever authenticate themselves.
None of the oauth2 flows seem to really match this, and we were wondering if there is a variation of the password grant type in which the password is not required for trusted client ID/Secret.
Some options we explored so far are offline tokens and user impersonation, but the former requires persisting secrets, and the latter relies upon proprietary Keycloak features using cookies rather than standard OIDC.
There's as of today an experimental oauth 2 token exchange grant type available in keycloak: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-19
As #qdivision pointed out: https://www.keycloak.org/docs/latest/securing_apps/index.html#direct-naked-impersonation
And Thomas Darimont: https://blog.softwaremill.com/who-am-i-keycloak-impersonation-api-bfe7acaf051a
Our team is starting to build out a SMART on FHIR (SoF) application. SoF uses OAuth2 access_tokens to represent authorizations. Our app is using the code grant to get a token (https://oauth2.thephpleague.com/authorization-server/auth-code-grant/).
I'm pretty new to OAuth2 (used to SAML) and have been reading up on the standard. I think we may be conflating what the access_token is intended to represent.
Is the intent in OAuth2 that the access_token represents the permissions the resource owner (end user) has granted to the client (web application) to perform on their behalf?
Or is the intent to rely that the resource owner (end user) is allowed to preform certain operations?
For example say the auth token request has a scope called 'contacts-update'. If we get an access_token back with this scope, does that mean the user has allowed the application to attempt to update contacts (on their behalf) or does it mean that the user has the underlying requirements (they are in the update contacts role) to be able to update contacts?
As you wrote, the OAuth2 access token represents a permission delegation from a resource owner to a client (application), so the client can perform operations on behalf of the resource owner. That's also why there is a consent page - the user agrees on giving the application permissions (scopes) it requested.
Sometimes, people want to use OAuth2 as a central authentication server and a permission configuration for their applications. They want each application to see all permissions the user has configured for it. Then it doesn't make sense for application to ask for specific scopes, but to configure the OAuth2 server to return all relevant for that application (identified by a client_id). But I don't think this is the intended way of usage and the OAuth2 specification doesn't cover this scenario.
OAuth2 can also be used for authentication only, if it supports OpenID Connect extension. Then applications can ask for ID tokens. ID token proves identity of a user and the permissions are handled in each application separately.
I'd like to authenticate a legacy java (6) application against a node-js one currently secured using keycloak OIDC bearer only (both apps belonging to same realm).
I've been told to use keycloak-authz-client library resolving a keycloak OIDC JSON as below
{
"realm": "xxx",
"realm-public-key": "fnzejhbfbhafbazhfzafazbfgeuizrgyez...",
"bearer-only": true,
"auth-server-url": "http://xxx:80/auth",
"ssl-required": "external",
"resource": "resourceName"
}
However, the keycloak java client required java 8 and my current runtime is a jre6. Recompiling the lib including transitive dependencies does not looks like a good idea and I end up so using keycloak oauth2 REST endpoint.
As far as I know oauth2 I would go with a client_credentials flows exchanging a client secret against an access_token once at application initialization and refreshing / renewing when expired.
Coming to keycloak documentation :
Access Type
This defines the type of the OIDC client.
confidential
Confidential access type is for server-side clients that need to perform a browser login and require a client secret when they turn an
access code into an access token, (see Access Token Request in the
OAuth 2.0 spec for more details). This type should be used for
server-side applications. public
Public access type is for client-side clients that need to perform a browser login. With a client-side application there is no way to
keep a secret safe. Instead it is very important to restrict access by
configuring correct redirect URIs for the client. bearer-only
Bearer-only access type means that the application only allows bearer token requests. If this is turned on, this application cannot
participate in browser logins.
It seems that confidential access type is the one suitable for my needs (should be used for server-side applications) however I don't get how it is related to browser login (which is my mind is related to authenticating using third parties identity providers as facebook and co).
The confidential client settings also require a valid redirect uri the browser will redirect to after successful login or lagout. As the client I want to authenticate is an application I don't see the point.
Generally speaking I don't get the whole access type things. Is it related only to the client or to the resource owner also (Is my node.js application stuck to bearer-only as existing clients use this access type ? will it accept the bearer authentication using the access_token obtained with client_credentials flow ? I suppose it will).
Can someone clarify keycloak OIDC access type and where I went wrong if I did ?
What is the proper way to delegate access for my legacy application to some resources (not limited to a specific user ones) of another application using keycloak ?
You are mixing up the OAuth 2.0 concepts of Client Types and Grants. Those are different, albeit interconnected, concepts. The former refers to the application architecture, whereas the latter to the appropriate grant to handle a particular Authorization/Authentication use-case.
One chooses and combines those options; first one choses the client type (e.g., public, confidential), and then the grant (e.g., Authorization code flow). Both client types share some of the same grants, with the caviar that the confidential client will require also a client secret to be provided during the execution of the Authentication/Authorization grant.
From the Oauth 2.0 specification:
OAuth defines two client types, based on their ability to
authenticate securely with the authorization server (i.e., ability to
maintain the confidentiality of their client credentials):
confidential
Clients capable of maintaining the confidentiality of their
credentials (e.g., client implemented on a secure server with
restricted access to the client credentials), or capable of secure
client authentication using other means.
public
Clients incapable of maintaining the confidentiality of their
credentials (e.g., clients executing on the device used by the
resource owner, such as an installed native application or a web
browser-based application), and incapable of secure client
authentication via any other means.
As one can read the client type refers to the type of the application architecture. Why do you need those types? The answer is to add an extra layer of security.
Let us look at the example of the Authorization Code Grant. Typically the flow is as follows:
The user goes to an application;
The user gets redirect to the Keycloak login page;
The user authenticates itself;
Keycloak check the username and password, and if correct, sends back to the application an authorization code;
The application receives that code and calls Keycloak in order to exchange the code for tokens.
One of the "security issue" with that flow is that the exchange of code for token happens on the frontend channel which due to the nature of browsers it is susceptible to a hacker intercepting that code and exchange it for the tokens before the real application does it. There are ways of mitigating this but it is out of the scope of this question.
Now, If your application is a single-page application, then it cannot safely store a secret, therefore we have to use a public client type. However, if the application has a backend where the client secret can be safely stored, then we could use a confidential client.
So for the same flow (i.e., Authorization Code Grant), one can make it more secure by using a confidential client. This is because the application will now have to send to Keycloak a client secret as well, and this happens on the backend channel, which it is more secure than the frontend channel.
What is the proper way to delegate access for my legacy application to
some resources (not limited to a specific user ones) of another
application using keycloak ?
The proper grant is to use the so called Client Credential Grant:
4.4. Client Credentials Grant
The client can request an access token using only its client
credentials (or other supported means of authentication) when the
client is requesting access to the protected resources under its
control, or those of another resource owner that have been previously
arranged with the authorization server (the method of which is beyond
the scope of this specification).
Since this grant uses the client credentials (e.g., client secret) you can only use it if you have selected confidential as the client type.
i'm implementing a REST layer for an existing application. I have my userid and passwords stored in database and i would like to authenticate these credentials while calling my REST services. Note that this is a standalone application.
After investigation, I figured out 2 ways.
Basic implementation with HTTPS - this approach makes sure that
userid and password passed is not tampered by Man in middle attack.
Using Authentication Token(JWT) - user initially passes his userid
and password and server gives back an Authentication token.Once user
have an authentication token that could be used for subsequent
request.
Using OAuth 2.0 - I'm very confused in this approach. After reading the docs and specification, I found that since my application
is standalone, I need to implement Authorization Server, Resource
Server etc.
I'm asked to implement OAuth here, but i'm not convinced that OAuth is required in this scenario. I'm more inclined towards just implementing JWT(tokens)
Is OAuth really mandated in this scenario. What i understand about OAuth is it is used when you already have a service like Facebook/ Google.
Could someone pls confirm if my train of thoughts are correct and if OAuth 2.0 is required in this case?
The primary goal of OAuth 2.0 is to allow users to authenticate to use a client application via a third-party authentication provider (e.g. Google, Facebook, etc.), without exposing their credentials (typically a username/password) to the client.
In your case, if users are only ever going to authenticate to your system using their credentials in your database, then implementing OAuth 2.0 doesn't add any substantial value for you.
The OAuth 2.0 specification does define a "Resource Owner Password Credentials grant", intended for legacy use cases, that would apply to your situation: a user sends credentials, and you return an access token (that could be a JWT, if you like). If it's desirable from a management or marketing perspective, you could implement the Resource Owner Password Credentials grant and legitimately state that your application "conforms to a subset of OAuth2, as defined by RFC6749".
Why would anyone use OAuth 2 with this kind of grant? I mean, if the client already has the name and password of the Resource Owner, why not just authenticate as the Resource Owner using whatever authentication vehicle is used by the Resource Server?
I do not understand the rationale here. Can someone explain it?
As the spec mentions, the Resource Owner Password Credentials grant is for migration purposes and applicable only in scenario's where (typically) the Client and the Authorization Server are controlled by the same party, https://www.rfc-editor.org/rfc/rfc6749#section-1.3.3:
The resource owner password credentials (i.e., username and password)
can be used directly as an authorization grant to obtain an access
token. The credentials should only be used when there is a high
degree of trust between the resource owner and the client (e.g., the
client is part of the device operating system or a highly privileged
application), and when other authorization grant types are not
available (such as an authorization code).
It allows for utilizing a standard token and protocol on the leg between Client and Resource server (e.g. OAuth 2.0 Bearer Token), whilst using a "to-be-deprecated" way of getting a token between Client and Authorization Server. https://www.rfc-editor.org/rfc/rfc6749#section-10.7:
The resource owner password credentials grant type is often used for
legacy or migration reasons. It reduces the overall risk of storing
usernames and passwords by the client but does not eliminate the need
to expose highly privileged credentials to the client.
This grant type carries a higher risk than other grant types
because it maintains the password anti-pattern this protocol seeks
to avoid. The client could abuse the password, or the password
could unintentionally be disclosed to an attacker (e.g., via log
files or other records kept by the client).
Additionally, because the resource owner does not have control over
the authorization process (the resource owner's involvement ends when
it hands over its credentials to the client), the client can obtain
access tokens with a broader scope than desired by the resource
owner. The authorization server should consider the scope and
lifetime of access tokens issued via this grant type.
The authorization server and client SHOULD minimize use of this
grant type and utilize other grant types whenever possible.
I will provide another point of view.
OAuth 2.0 is a great protocol for common web applications. Some applications, however, use much stronger authentication / authorization mechanism. For these cases, it makes sense to allow token establishment using a strong method. An example of such application can be a banking API - it can use classic OAuth 2.0 flow on web (using bank's website) and strong data signatures using protocols like PowerAuth 2.0 (I am an author of this solution) for native mobile or desktop apps.