It seems that for OIDC certification, we will need more proper support
for "scope" parameter. There are few tests from OIDC conformance
testsuite, which end with WARNING because of issues with "scope" parameter.
SUMMARY OF SPECS REQUIREMENTS
- In OIDC specification, the "scope" parameter is actually REQUIRED. And
you must add the scope value "openid" to all authorization requests.
Hence if you don't use "scope=openid", the request is pure OAuth2
request, but it's not OIDC request.
In https://issues.jboss.org/browse/KEYCLOAK-3147 we discuss the
possibility that we should change our adapters and add "scope=openid" to
all requests, and also the possibility to remove IDToken if it's not
OIDC request (and maybe other things). However it may be potential issue
with backward compatibility with older adapters (which don't add
"scope=openid" at all).
- OIDC also prescribes the "scope=offline_access", which you use if you
want offline token. We actually support this as we have realm role
"offline_access", with scopeParamRequired=true . So this role is applied
just if it's included in scope parameter. This is our only support of
scope param actually. ATM we reference the realm roles by name (role
name must match the value of scope parameter) and clientRoles by
"clientId/roleName" . So it's not very flexible and won't work well in
the future with role namespaces.
- OIDC defines four other scope values, which we don't support, with the
meaning like this:
OPTIONAL. This scope value requests access to the End-User's
default profile Claims, which are: "name", "family_name", "given_name",
"middle_name", "nickname", "preferred_username", "profile", "picture",
"website", "gender", "birthdate", "zoneinfo", "locale", and "updated_at".
OPTIONAL. This scope value requests access to the "email" and
OPTIONAL. This scope value requests access to the "address" Claim.
OPTIONAL. This scope value requests access to the "phone_number"
and "phone_number_verified" Claims.
- Not directly related to scopes, however OIDC also has one parameter
"claims" described in section
This allows to define some additional claims, which should be included
in IDToken or UserInfo endpoint in addition to claims specified by
HOW TO IMPLEMENT?
My current thinking is, that we will have 2 kinds of protocolMappers and
1) "Always applied" - Those roles/protocolMappers are always applied to
token even if they are not specified by scope parameter.
2) "Applied on demand" - Those roles/protocolMappers are applied just if
they are specifically requested by scope parameter
For roles, we already have that with "scope param required" flag defined
per roleModel. However for protocolMappers we don't have it yet.
IMO We will also need some more flexible way to specify how the value of
scope parameter will be mapped to roles and protocolMappers. For example
if I use "scope=foo", it can mean that I want realm role "foo1", client
role "client1/foo2" and protocolMapper for "firstName" and "lastName" etc.
I can see 2 possibilities:
a) Configure allowed scope param separately per each role / protocolMapper
If some role has "Scope param required" checked, you will have
possibility to configure list of available values of scope parameter,
which this role will be applied to. This will be configured per-each
Example: I have realm role "foo" . I check "scope param required" to
true. Then I will define "scope param values" : "bar" and "baz". It
means that if someone uses parameter "scope=bar" or
scope=baz", then role "foo" will be applied to token. Otherwise it won't
Similarly it will be for protocolMappers. We will add switch "Scope
param required" to protocolMappers and we will use list of available
values of scope parameter, which is configured per each protocolMapper
b) Configure scope parameter in separate place
We will have another tab "Scope parameter config" (or maybe rather
another sub-tab under existing "Scope" tab). Here you will define the
allowed values of scope parameter. For each allowed value, you will
define protocolMappers and roles to apply. Hence for example for
"profile" scope parameter, you will define all protocolMappers for
corresponding claims ( name, family_name, ...) here.
We will still need "scope param required" switch for protocolMappers in
My current thinking is to go with (a). So when you go to some role (or
protocolMapper) in admin console you will see if you need scope
parameter and what are available values of scope parameter to request it.
WDYT? Another ideas?
Hi Keycloak Developers,
RFC6750 allows the access token to be submitted as part of a POST
request. I found that this is the only good way to do file downloads in
Excerpt: When sending the access token in the HTTP request entity-body,
client adds the access token to the request-body using the
"access_token" parameter. [...] Resource servers MAY support this method.
I don't remember a thread on this mailing list. The only place I could
find in the code was the User Endpoint that does this quite manually.
Currently Keycloak only supports the query parameter using
QueryParamterTokenRequestAuthenticator. A similar class will be needed
to support a Form Parameter. Like the
QueryParamterTokenRequestAuthenticator it will be part of the request
processing and it will not be configurable.
I'd like to open a JIRA issue for this as part of the Java Keycloak
Clients to track the efforts and thoughts.
Alexander Schwartz (alexander.schwartz(a)gmx.net)
Hi keycloak developers,
I like this idea to be able to disable keycloak with a property. It
would be useful in the keycloak-spring projects that I've seen
The convention with other libraries is usually to add a property like
to the spring boot configuration file and a
@ConditionalOnProperty(value = "keycloak.enabled", matchIfMissing = true)
to the spring autoconfiguration.
What do you think? If this is OK-ed, I'll open a JIRA and prepare a PR.
Am 10.03.2017 um 16:49 schrieb Pavel Maslov:
> Hi all,
> Sometimes (for testing purposes) I need to disable keycloak security
> Is it possible to do so via application.properties file? Right now
> apart from the properties file I also have to comment out these
> dependencies and rebuild the project:
> compile 'org.keycloak:keycloak-spring-boot-adapter:2.5.1.Final'
> compile 'org.keycloak:keycloak-tomcat8-adapter:2.5.1.Final'
> Pavel Maslov, MS
> keycloak-user mailing list
Alexander Schwartz (alexander.schwartz(a)gmx.net)
In the past some systems inside my company were using a custom made sso
implementation that had the ability to do silent login among them.
On of that systems was completly refactored and is using keycloak for
authentication and authorization. Since than, we lost that silent login
feature with the other systems.
We assumed that it was ok to lost this feature for a while but now we are
trying to implement the silent login again.
- System "A" is using keycloak with a realm "RealmA" with multiple clients
(modules) with sso between them.
- Other systems "B", "C" with their custom authentication and authorization
- We are using a custom federation on keycloak over the same users database
that is shared among all the systems.
What's the best practise to achieve sso between all the systems?
We are thinking about a proxy that detects if the user has a session on
some of the other systems and if that is true, we programatically create a
session on keycloak for a given (Is this possible with the API?).
While trying to fix https://issues.jboss.org/browse/KEYCLOAK-4342 I
realized that I need to have the application context path.
The fix is for the CookieTokenStore, it's failing currently when no
application context is set (for instance a Spring Boot or WF Swarm app
running directly under localhost:8080). (details are in the ticket)
I was hoping to rely on this method getRelativePath();
but for the Undertow implementation for instance , it returns an empty
So, we could add a seperate method on the HttpFacade (or the
KeycloakDeployment object) that returns the application context path, it's
not trivial since it needs to be added to all the adapter implementations.
I have an idea how step up authentication could work with Keycloak that I'd
like to share.
Clients require certain authentication steps by using scopes linked to
An authenticator would only be executed if it's scope is present.
An application can detect the current authentication level by inspecting
OIDC token or SAML assertions and request additional authentication if
All that with (IMHO) a few little additions to Keycloak.
The main idea is to have a new option 'Scope Param Required' for
there is for Roles. If 'Scope Param Required' is "On" then the
only executed if the scope parameter in the login URL contains the
provider id, e.g. 'auth-otp-form'.
On the client / adapter side there could be a new configuration property
'additional-scopes' to specify a required authentication scope.
Optionally there could be an additional property 'required-claims:
indicate that a user can only access the app if the given claim is present.
Authenticators could also by default emit a 'User session note' with the
provider id to
indicate that they were executed, e.g. "auth-otp-form: true".
This could then be mapped via a protocol mapper into a OIDC token / SAML
(for OIDC one could also configure an ACR level that is provided by an
but this wouldn't help for SAML)
With this clients could detect the executed authenticators based on the
claims in the
OIDC token (or ACR value) or SAML assertions and trigger reauthentication
if necessary, e.g. by sending a
redirect to the '/auth' URL with parameters 'prompt=login' and
Example Scenario (OIDC):
In realm 'acme' we have two clients 'A' and 'B'.
To access 'A' username/password authentication is enough, but for 'B' one
needs to provide an
additional factor, e.g. an OTP token or code via SMS.
The auth-otp-form authenticator is configured with 'Scope Param Required=On'
B's adapter config contains 'additional-scopes: auth-otp-form'
First the user accesses 'A' and authenticates with username-password. Then
the user tries
to access 'B'. 'B' detects that the current OIDC (access/ID) token doesn't
required claim 'auth-otp-form'. Thus it sends a redirect as mentioned
Keycloak would now detect that it needs to execute the OTPForm authentiator
based on the scope
parameter auth-otp-form which will prompt the user for OTP input.
Note that the user still would need to provide his username/password. If
one would be able to skip
that (since the user is already authenticated via username/password) one
could think of an additional
parameter like 'auth_mode=step_up' to signal Keycloak that it should only
verify credentials that have not yet checked.
In this case it would skip the username / password authenticator and jump
to the OTP form.
What do you think?