We have direct grants where client passes username and creds to obtain
a token for that user. We have client credentials grant to get a
token for the client itself.
What if we had a direct exchange where the client provides user id or
username and gets a token for that user? The client does not have to
provide user credentials.
What is the use case for this? Consider an application that is
authenticated via an external mechanism. Consider that this external
mechanism does not provide any type of token, it just authenticates a
username. This application needs to talk to services secured by
Keycloak. So, with this new direct exchange mechanism, the
application only needs to have a client account on the Keycloak server
to obtain a token for a keycloak user. Another benefit of this is
that Keycloak does not need to understand external token formats in
order to provide a token to a client that authenticates users by an
There's some big security risks for this. If the client's secret is
stolen the attacker would be able to mint token for any user. This
is somewhat mitigated in two ways:
a) If the token is minted for the client, the scope of the token can
be limited, i.e. role mappings limited
b) if the client is asking for a different audience (a different
client) the client can be limited on the audience it can ask for. (we
already do this check for client to client token exchange).
Thanks to Rubén  we have successfully changed our customization to
Keycloak Docker images using jboss-cli and embed-server, instead of XSLT
In the past Stian has suggested that the XSLT was done before
embed-server was available .
We would like to contribute some of this changes to the base images. Can
we log an issue and send a pull request?
The proposed changes will be just to remove xlst transformations with
The new Angular 2 Account Management Console just got its first commit
to master. This console will be extensible, allowing new pages to be
added. It will have a better look and feel as it adheres to PatternFly
standards. Also, it looks nice on your phone.
If you'd like to take a peek, you will need to build keycloak with an
"account2" profile ( mvn install -Paccount2 )
Then when you run the server, use this system property:
After that, just log in to the admin console and set the account theme
Don't expect full functionality just yet. There is a lot of work to do
on the back end with our new account management REST endpoints.
I was wondering why migration-*.cli scripts contain migrations for
It makes perfect sense that they are used to adjust configuration of other
wildfly subsystems that we don't control. But for keycloak-server I imagine
all migration should be performed at runtime by keycloak-server subsystem
itself. This way migration is easier to do, it involves fewer modules in
our build, fewer files (no /subsystem=keycloak-server entries in
migration-*.cli files), and it's testable in a single module.
Any reason why not do it that way?
Another thing - currently our (de facto) versioning policy for keycloak
subsystems is to not increment the version as long as the old syntax/model
keeps working, even if we introduce new xml syntax we keep the old version
In practice that means that if I see an example of subsystem configuration
somewhere, and I copy it to the older version of Keycloak (why not, it says
it's still version 1.1) that would not work if it contains any later syntax
that older version doesn't understand. Older keycloak-server configuration
can be copied to newer version of Keycloak without issues.
That's simple for us to maintain, and seems to work well enough.
Technically we'll only have to increment version if we decide to break
backwards compatibility of the configuration - nowhere on our radar ATM.
Does anyone see this policy as problematic?
This place is surely better than a comment in JIRA. I really need this
issue to be resolved. I tried a fistr patch quickly, which was
rejected, but is it possible to verify the credential type befoer
the password policy check in UserCredentialStoreManager.java or is it
the wrong direction?
It seems like token introspection for pairwise tokens report access tokens
with a pairwise sub as inactive when they're actually active. User lookup
is using the sub instead of the session. It's a quick fix. Should I JIRA it
and submit a PR?
Tomcat 6 test is failing on my box. I pulled fresh copy of master and
removed org/keycloak from .m2. So I don't think its anything local on
Currently when you use the otp feature, on signup it shows the qr code (derived from a uri generated based on https://github.com/google/google-authenticator/wiki/Key-Uri-Format), and it shows the encoded private key that you can copy and paste to google authenticator.
The issues we've experienced is thatkeycloak allows you to choose your otp algorithm, i.e. SHA256, whilst google authenticator uses SHA1. When you scan the qr code it works well, given it adds the algorithm to the uri, and it gets added to google authenticator correctly. The problem is that if you are accessing this via a mobile phone, you cannot scan the qr code and you have to copy the code to google authenticator, which is clunky and doesn't work for certain scenarios. When you do this, you have no way (that I can see) to set which algorithm to use in google authenticator, it just assumes SHA1 and if the algorithm in keycloak is set to any other algorithm, it is added to google authenticator but keycloak says code is invalid. Regardless of the algorithm issue, this is also not a great user experience for a mobile user.
The proposed solution is to check if the browser is running on a mobile device, and if so, have an html button that opens the same link that is embedded in the qr code.
I'm happy to do a PR for this.
Looking forward to your feedback.
This e-mail is subject to a disclaimer, available at http://www.rmb.co.za/web/elements.nsf/online/disclaimer-communications.html
There are few things, which can be improved with current implementation
of authenticatedClientSessionModel, codeToToken endpoint and refresh
Here is some overview of the current issues:
1. The UserSessionModel currently contains just 1
authenticatedClientSession per client.
The issue is, that if there are multiple browser tabs for same client
application, they may not have same notes, protocolMappers and roles
(for example if we limit the roles based on "scope" parameter, the roles
can be different in browser tab1 and tab2 as every tab can have
different scope parameter. This is not big issue now, since we don't
have proper support for "scope" parameter, but could be in the future..)
2. The authenticatedClientSession is currently needed in code-to-token
request. This is a bit of perf issue in cross-dc. The code-to-token
request can happen in different DC then authentication. It will be ideal
if code-to-token request doesn't need to wait until userSession with
attached authenticatedClientSession is replicated from the second DC
3. There is just 1 valid code per authenticatedClientSession tracked in
the attached note - in case that 2 user sends 2 concurrent requests to
http://localhost:8080/customer-portal, it may happen that there are 2
SSO logins concurrently issued, however just 1 of them will successfully
pass the code-to-token request (clientSession note will be overwritten
by the second request, so first request will fail in code-to-token
request due the different note value)
4. Refresh token is signed by same key like accessToken. This is not
- performance (RSA is an unecessary overhead. Symmetric cryptography is
- Security: Refresh tokens and access tokens can be exchanged. Refresh
token is JWT visible by application and end user (not direct security
Possible solution proposal:
- Move some stuff from authenticatedClientSessionModel to the code
parameter and refreshToken itself.
- Code will be encrypted JWT containing just clientSession notes. Not
the protocolMappers and roles
- Refresh token will contain both roles and protocolMappers (roles are
here already. The protocolMappers will be new thing on refresh token)
- Both code and refreshToken are AES-128 encrypted. Just the keycloak
server has the key and can decrypt them.
- AuthenticatedClientSessionModel won't contain protocolMappers and
- Use single-use cache to track whether the particular value of code
parameter was already used.
I've tried the code to be signed instead of encrypted, but it may have
security implications (code would be visible by adapters and end-user).
The roles and protocolMappers are not needed in code and keeping them
would make the code unecessary big (URL limit is 2000 characters).
I've tried to add more details into the Google document:
. Feel free to reply in the document or here in the email.