Example Setup to simplify the development of Keycloak Extensions
by Thomas Darimont
Hello Keycloak-Team,
I found a neat setup to simplify the development of Keycloak extensions.
I setup a "keycloak-extension-playground" project that contains two or more
maven modules:
- keycloak-playground-server
- simple-auth-extension (example)
In the "keycloak-playground-server" module, I wrap a KeycloakServer from
the "keycloak-testsuite-utils" library where one could potentially add
additional configuration. Note that this library must be in (local) Maven
Repository.
The "simple-auth-extension" is an example extension module that
demonstrates the usage of the Authenticator SPI.
I now declare "simple-auth-extension" as a compile time dependency of the
"keycloak-playground-server" project. This ensures that it's classes and
resources are on the classpath of KeycloakServer. Therefore all SPI
implementations in custom extensions can be found. This improves the
debugging experience and speeds up development time.
The example project can be found here:
https://github.com/thomasdarimont/keycloak-extension-playground
What do you guys think about this approach?
Cheers,
Thomas
7 years, 1 month
Introduce GolangCI to Gatekeeper repository
by Bruno Oliveira
Good morning,
A week ago Frederic, one of our contributors, suggested the
inclusion of GolangCI[1][2]. For those not familiar,
GolangCI can run a set of linters against the source tree. It can
check if the code respects the code style, if there are vulnerabilities
introduced into the codebase and also advise on best practices.
Even though I think it's something nice to have, I'm afraid that
GolangCI could add too much noise commenting on PRs (I'm not
sure if this can be disabled).
Even though is something cool, I'm 50/50 on this. I don't see the
adoption from big projects like Openshift or Kubernetes.
Thoughts?
[1] - https://github.com/keycloak/keycloak-gatekeeper/pull/454
[2] - https://golangci.com/
--
abstractj
7 years, 1 month
Re: [keycloak-dev] OIDC Discovery-enabled IdentityProvider
by James Campbell
All--
Thanks to Stian's recommendations for similar features in the codebase,
I've developed a proposal for how to implement this feature, and sketched
out an initial implementation. As he suggested, I'd like to get feedback
before opening up a PR.
1. We introduce a new subclass of the OIDCIdentityProvider / Factory called
OIDCDiscoveryIdentityProvider. The new class adds a discoverConfig method
that can be used to discover and set all relevant endpoints in a
configuration except the issuer. Issuer then becomes the sole required
element of the config. (So the GoogleIdentityProvider, for example, will
then just call discoverConfig with its hard-coded issuer).
-> During the parseConfig call, the Factory will raise a
RuntimeException if the config cannot be obtained, since if the config can
never be obtained there is no way to have a valid configuration at all.
-> During the discoverConfig call, we return the cached value, and
optionally refresh it based on when we last obtained the configuration.
-> In the event of a failure in the *refresh* I'm imagining the best
behavior is to log a warning but then return the cached config (last known
good config).
2. We introduce an SPI and interface called
OIDCDiscoveryRepresentationProvider / Factory and implementations called
Infinispan... which obtains OIDCConfigurationRepresentations using the
/.well-known/openid-configuration endpoint on the issuer.
I have a couple questions:
1. I began an implementation of this, but the @JsonProperty annotations on
the existing OIDCCOnfigurationRepresentation class seem to be ignored when
I try to have it read from the openid-configuration docuement, e.g.:
- OIDCConfigurationRepresentation rep = SimpleHttp.doGet(issuer +
"/.well-known/openid-configuration",
session).asJson(OIDCConfigurationRepresentation.class); // FAILS with
"Unrecognized field ..." Perhaps a mismatch of the jackson annotation
version in the keycloak-model-infinispan submodule?
2. Assuming the design above makes sense, what is the right way to plug
this into the testing framework? Is one of the core developers interested
in tackling that aspect if I push a PR with the above features implemented?
James
On Sun, Jan 27, 2019 at 11:15 AM James Campbell <james.p.campbell(a)gmail.com>
wrote:
> Got it; I checked that code out and it does look like a pretty direct
> model for the refreshing feature. I'll begin working on a PR.
>
> On Mon, Jan 21, 2019 at 3:25 AM Stian Thorgersen <sthorger(a)redhat.com>
> wrote:
>
>> JWKs used by identity brokering and client authentication.
>>
>> On Sat, 19 Jan 2019 at 23:29, James Campbell <james.p.campbell(a)gmail.com>
>> wrote:
>>
>>> Stian--
>>>
>>> Thanks for confirming. Which keys are you referring to--I'll take a look
>>> at that in the code and try to follow that pattern closely.
>>>
>>> James
>>>
>>> On Wed, Jan 16, 2019 at 1:52 AM Stian Thorgersen <sthorger(a)redhat.com>
>>> wrote:
>>>
>>>> It would be good to get these changes included. We do something similar
>>>> for the keys today and they are cached in an Infinispan local cache. Could
>>>> do something similar for the OIDC discovery/config.
>>>>
>>>> On Tue, 15 Jan 2019 at 17:44, James Campbell <
>>>> james.p.campbell(a)gmail.com> wrote:
>>>>
>>>>> Tomas--
>>>>>
>>>>> Thanks--it certainly seems close, you're right! It looks, however like
>>>>> an
>>>>> OIDC provider still uses a static configuration even though it loads it
>>>>> from the discovery URL--that is, once it's loaded at configuraiton
>>>>> time, it
>>>>> doesn't discover new changes, and there isn't an option to
>>>>> refresh/store
>>>>> that discovery endpoint outside of configuration.
>>>>>
>>>>> It's not clear to me how important that feature is--on one hand, it
>>>>> seems
>>>>> unlikely that we should expect frequent changes; on the other, in the
>>>>> short
>>>>> time since I started exploring this setup, I have encountered three
>>>>> changes
>>>>> in google's OIDC endpoints between what was hard-coded into keycloak,
>>>>> what
>>>>> is in their documentation, and what their current discovery endpoint
>>>>> provides. (And, the google docs specifically suggest refreshing from
>>>>> the
>>>>> endpoint periodically).
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> James
>>>>>
>>>>>
>>>>> On Tue, Jan 15, 2019 at 10:31 AM Tomas Kyjovsky <tkyjovsk(a)redhat.com>
>>>>> wrote:
>>>>>
>>>>> > Please disregard my previous message.
>>>>> >
>>>>> > Looking at the docs [1] and the Admin Console UI this should be
>>>>> already
>>>>> > possible with the OIDC identity provider.
>>>>> > When creating a OIDC identity provider in the Admin Console there is
>>>>> an
>>>>> > option at the bottom of the page to import OIDC configuration
>>>>> metadata from
>>>>> > URL.
>>>>> >
>>>>> > Does this cover your use case?
>>>>> >
>>>>> >
>>>>> > Regards,
>>>>> > Tomas
>>>>> >
>>>>> > [1]
>>>>> >
>>>>> https://www.keycloak.org/docs/latest/server_admin/index.html#openid-conne...
>>>>> >
>>>>> >
>>>>> > ----- Original Message -----
>>>>> > > Hello James,
>>>>> > >
>>>>> > > See my 2 cents inline..
>>>>> > >
>>>>> > > ----- Original Message -----
>>>>> > > > All--
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > After observing that the Google Social Identity Provider in
>>>>> Keycloak
>>>>> > was
>>>>> > > > using a deprecated userprofile endpoint [
>>>>> > > > <https://issues.jboss.org/projects/KEYCLOAK/issues/KEYCLOAK-9179
>>>>> >
>>>>> > > > Keycloak-9179, <https://issues.jboss.org/browse/KEYCLOAK-9169>
>>>>> > > > Keycloak-9169], I wanted to propose the creation of an
>>>>> IdentityProvider
>>>>> > > > that
>>>>> > > > will use the OIDC Discovery mechanism to dynamically build a
>>>>> config [
>>>>> > > > <https://issues.jboss.org/browse/KEYCLOAK-9194> Keycloak-9194].
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > I see a few decision points along the way that I wanted to ask
>>>>> about
>>>>> > before
>>>>> > > > an implementation, since I'm very new to keycloak and just
>>>>> starting to
>>>>> > > > understand the codebase. In particular, I wondered if this group
>>>>> could
>>>>> > > > share
>>>>> > > > insight into these couple issues so I can make a more informed
>>>>> design:
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > 1. It looks to me like the actual IdentityProviders are
>>>>> instantiated
>>>>> > > > just
>>>>> > > > as they're being used, but that the models are persisted in the
>>>>> > RealmModel.
>>>>> > > > It's not clear to me where the separation of concerns is
>>>>> supposed to be
>>>>> > > > between the IdentityProvider and the IdentityProviderModel-in
>>>>> > particular
>>>>> > > > since the GoogeIdentityProvider, say, immediately sets endpoints
>>>>> in its
>>>>> > > > constructor. Normatively, where *should* social identity
>>>>> providers'
>>>>> > model
>>>>> > > > configuration be set (and, e.g., where are the models first
>>>>> added to
>>>>> > the
>>>>> > > > RealmModel)?
>>>>> > >
>>>>> > > Provider classes are being instantiated per transaction by their
>>>>> > > corresponding ProviderFactories and then left to be
>>>>> garbage-collected
>>>>> > after
>>>>> > > Provider.close() is called.
>>>>> > > The Provider class is given its configuration
>>>>> (IdentityProviderModel in
>>>>> > this
>>>>> > > case) by its factory which I believe loads it from cache/jpa
>>>>> layer. Any
>>>>> > > class extending AbstractIdentityProvider should then be able to
>>>>> access
>>>>> > its
>>>>> > > config via getConfig() method but I don't think it will be able to
>>>>> > > update/persist it back. The provider configuration/model itself is
>>>>> > managed
>>>>> > > by the IdentityProviderResource (REST endpoint accessible via REST
>>>>> or
>>>>> > admin
>>>>> > > console UI) in the keycloak/services module so I think the
>>>>> > > auto-configuration logic would have to be placed somewhere there.
>>>>> > >
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > 2. I see that there is logic to parse OIDC Discovery
>>>>> configuration
>>>>> > as
>>>>> > > > part of configuring Keycloak itself as an OIDC provider /
>>>>> implementer
>>>>> > of
>>>>> > > > OIDC protocol (including building and parsing the .well-known
>>>>> config
>>>>> > > > elements), but that logic seems not to be used in any setting
>>>>> > currently as
>>>>> > > > a
>>>>> > > > client. Should I plan to reuse, say, the
>>>>> > OIDCConfigurationRepresentation
>>>>> > > > and
>>>>> > > > OIDCWellKnownProvider classes for their logic in handling such
>>>>> configs?
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > Currently, I'm imagining something along the lines of extending
>>>>> > > > OIDCIdentityProvider with a new OIDCDiscoveryIdentityProvider
>>>>> that
>>>>> > adds a
>>>>> > > > discoverConfig method which can be used by an implementing class
>>>>> (such
>>>>> > as
>>>>> > > > GoogleIdentityProvider) to discover and cache endpoints such
>>>>> that they
>>>>> > are
>>>>> > > > not hard-coded into the implementing class. Each implementing
>>>>> class
>>>>> > would
>>>>> > > > then have a public static final DISCOVERY_URL that it passes to
>>>>> > > > discoverConfig.
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > My main hangup, as suggested above, is that to implement the
>>>>> caching, I
>>>>> > > > want
>>>>> > > > to ensure that the model configuration is stored/set in the right
>>>>> > place.
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > Thanks for bearing with me as I come up to speed on this!
>>>>> > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > James
>>>>> > > >
>>>>> > > > _______________________________________________
>>>>> > > > keycloak-dev mailing list
>>>>> > > > keycloak-dev(a)lists.jboss.org
>>>>> > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>> > > >
>>>>> > >
>>>>> > >
>>>>> > > Regards,
>>>>> > > Tomas
>>>>> > >
>>>>> >
>>>>>
>>>>>
>>>>> --
>>>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>>>>> -...
>>>>> . / ..-. .. -
>>>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>>> _______________________________________________
>>>>> keycloak-dev mailing list
>>>>> keycloak-dev(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>>
>>>
>>> --
>>> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- /
>>> -... . / ..-. .. -
>>> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>>>
>>
>
> --
> -... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- / -...
> . / ..-. .. -
> 07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
>
--
-... . / - .-. ..- . .-.-.- / -... . / .--. .-. . ... . -. - .-.-.- / -...
. / ..-. .. -
07:d0:2d:0b:d6:9d:27:c6:a7:c1:ec:e3:b1:65:f4:70
7 years, 1 month
Running custom scripts in Keycloak container image
by Sebastian Laskawiec
Hey guys,
A while ago, one of our contributors, Wouter, sent an interesting pull
request: https://github.com/jboss-dockerfiles/keycloak/pull/176
The aim is to allow running custom scripts just before Keycloak boots up
and after the main configuration is done. This allows a user to inject his
own scripts (even *.cli) into /opt/jboss/tools/docker-entrypoint.d and
execute them automatically.
This is somewhat related to what the Integrately Team is doing. They
basically use an InitContainer [1] to put additional extensions into our
image. Perhaps with the proposed approach, they could embed a custom script
that would download whatever extensions they need and put them into the
deployments directory?
After thinking about this for a while, and besides really good advantages
of the Pull Request, I have some doubts. The biggest one is about our
guarantees with regard the Keycloak distribution (by saying distribution I
mean the binaries, their structure and Keycloak server location in the
image). If we accept this approach, it will be pretty hard for us to change
any major thing (even some trivial things like the location of the Keycloak
Server) without breaking the client scripts.
Personally, I'm slightly leaning towards accepting this feature, but with a
description in README, that the user scripts may break at any time and in
any version (maybe even we should print this message in our logs). This way
we'll make the contract for such scripts very clear.
What do you think?
Thanks,
Sebastian
[1] https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
7 years, 1 month
Certificate subject DN is provider dependent
by Lösch, Sebastian
Hello Keycloak developers,
I am currently working on configuring keycloak for X.509 certificate login.
We store the whole user certificate's subject DN as user attribute. During the login we match the authentication certificate's subjectDN against the value stored in the user attributes.
The subject DN is determined executing:
cert.getSubjectDN().getName()
Here we have a problem regarding the subject DN order. We realized that the subject DN order is security provider specific:
· Using SUN security provider we get a subject DN like:
"EMAILADDRESS=bjensen(a)example.com, CN=Ms. Barbara J Jensen III, O=example.com, ST=California, C=US"
· Using BouncyCastle security provider we get a subject DN like:
"C=US,ST=California,O=example.com,CN=Ms. Barbara J Jensen III,E=bjensen(a)example.com"
This is obviously a problem.
Does anybody else ran into the same problem?
In my opinion it would be better to use:
cert.getSubjectX500Principal().getName(X500Principal.CANONICAL)
to determine the subject DN, as the result is provider independent.
But this would be an backward incompatible change in Method
org.keycloak.authentication.authenticators.x509.AbstractX509ClientCertificateAuthenticator.UserIdentityExtractorBuilder.fromConfig()
What is your opinion?
Best regards
Sebastian
--
Solution Engineering
--
Governikus GmbH & Co. KG
Hochschulring 4
28359 Bremen, Germany
Phone: +49 421 204 95 - 28
Fax: +49 421 204 95 - 11
E-Mail: Sebastian.Loesch(a)governikus.de<mailto:Sebastian.Loesch@governikus.de>
www.governikus.de<http://www.governikus.de/>
--
Governikus GmbH & Co. KG
Aufsichtsratsvorsitzender: Dr. Martin Hagen | Amtsgericht Bremen HRA
22041
Geschäftsführer: Dr. Stephan Klein
Persönlich haftende Gesellschafterin: Governikus Bremen GmbH
Geschäftsführer: Dr. Stephan Klein | Amtsgericht Bremen HRB 18756
****************************************************
Wir sind umgezogen! Bitte beachten Sie unsere neue Anschrift: Hochschulring 4, 28359 Bremen
Veranstaltungsvorschau: Besuchen Sie uns...
Dataport Hausmesse | 02.04.2019 | Hamburg - Schnelsen<https://www.dataport.de/Seiten/Aktuelles/Veranstaltungen/190402-Hausmesse...>
Digitaler Staat | 02. + 03.04.2019 | Berlin<https://www.digitaler-staat.org/>
7. Zukunftskongress Staat & Verwaltung | 27. - 29.05.2019 | Berlin<https://www.zukunftskongress.info/de>
Kongress Baden-Württemberg | 04.07.2019 | Stuttgart<https://www.bw-4-0.de/>
[cid:image8a82cf.JPG@26f9b88d.448c29be]<http://www.jahrestagung.governikus.de/>
7 years, 2 months
UMA specs submitted to IETF
by Pedro Igor Silva
Hi,
The UMA work group did an important move this week by contributing [1] UMA
2.0 specs to IETF.
As an OAuth2 extension, UMA aims to leverage OAuth2 in order to support
asynchronous authorization, loosely coupled AS, clients and resource
servers (in regards to authorization to protected resources) as well as
give to resource owners more control over the permissions that govern
access to their protected resources.
Regards.
Pedro Igor
[1] https://mailarchive.ietf.org/arch/msg/oauth/r1mFPzQaXy322wSR3my5i1uCdXQ
7 years, 2 months
Re: [keycloak-dev] Client and Service Account Session
by Zaunegger, Jörg
Hi Thomas,
thanks. Of course I will give it a try.
Today I did also try to find a solution by myself.
Because we are using AccessTokens in our applications to access other applications, we will having the problem not only with spring-boot-admin. What do you think about caching the AccessTokenResponse.
If the AccessToken is not valid but the RefreshToken is, then we obtain a new AcessToken with that RefreshToken. If the RefreshToken is no longer valid, we obtain a new token with the credentials of the service account.
It seems to work. Do you see any problem with this solution?
Cheers Jörg
Von: Thomas Darimont <thomas.darimont(a)googlemail.com<mailto:thomas.darimont@googlemail.com>>
Gesendet: Mittwoch, 13. Februar 2019 16:27
An: Zaunegger, Jörg <Joerg.Zaunegger(a)kvbawue.de<mailto:Joerg.Zaunegger@kvbawue.de>>
Cc: keycloak-dev(a)lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
Betreff: Re: [keycloak-dev] Client and Service Account Session
Hello Jörg,
I built an example app that demonstrates this spring-boot-admin / Keycloak setup.
Would it help to use offline_tokens for the spring-boot-admin service account instead of normal refresh-tokens?
Unfortunately the Keycloak Admin client library currently does not support custom scopes like scope=offline_access.
I just pushed a PoC with patched offline_access support via a custom TokenManager. Would you mind giving it a try?
https://github.com/thomasdarimont/spring-boot-admin-keycloak-example/tree...
Cheers,
Thomas
Am Mi., 13. Feb. 2019 um 10:43 Uhr schrieb Zaunegger, Jörg <Joerg.Zaunegger(a)kvbawue.de<mailto:Joerg.Zaunegger@kvbawue.de>>:
Hi Pedro,
In our application we are securing spring-actuator endpoints with a keycloak role. These endpoints are requested repeatedly (every 5 s) by an application called spring-boot-admin<https://github.com/codecentric/spring-boot-admin>. For the request spring-boot-admin obtains an AccessToken. Because there is a session for each request, we have thousands of open sessions for the service account of spring-boot-admin.
Any news, suggestions or solutions on avoiding these open sessions?
Thanks.
Jörg Zaunegger
-----Ursprüngliche Nachricht-----
Von: keycloak-user-bounces(a)lists.jboss.org<mailto:keycloak-user-bounces@lists.jboss.org><mailto:keycloak-user-bounces@lists.jboss.org<mailto:keycloak-user-bounces@lists.jboss.org>> <keycloak-user-bounces(a)lists.jboss.org<mailto:keycloak-user-bounces@lists.jboss.org><mailto:keycloak-user-bounces@lists.jboss.org<mailto:keycloak-user-bounces@lists.jboss.org>>> Im Auftrag von Pedro Igor Silva
Gesendet: Montag, 13. November 2017 09:52
An: keycloak-dev(a)lists.jboss.org<mailto:keycloak-dev@lists.jboss.org><mailto:keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>>
Betreff: RE: [keycloak-dev] Client and Service Account Session
Hi,
Currently, every time a confidential client tries to get a new access token
from the token endpoint a new session is created on the server. This can
lead to multiple active sessions for a single client/service account when
doing multiple requests to token endpoint.
To avoid that the client should store the access token/refresh token and
use a refresh token when appropriate in case the access token has expired.
That is fine.
Now, suppose a confidential client is deployed and wants an access token. A
new session will be created on the server. In case the application goes
down for some reason (e.g.: container moved to a different node in
kubernetes and without a persistent volume) and tries to get a new access
token, we may end-up with two active sessions when asking for a new token
after a re-deploy.
What are your thoughts about re-using existing sessions when doing client
credentials ? What could be the impact on clustering if we need (and we'll
probably need) to update the session ?
Another question would be ... Does make sense to also enable clients to
obtain tokens without necessarily creating a session on the server ? I
think that in most cases, you don't really want to keep track of sessions
when doing client credentials.
Regards.
Pedro Igor
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
7 years, 2 months
Re: [keycloak-dev] Client and Service Account Session
by Zaunegger, Jörg
Hi Pedro,
In our application we are securing spring-actuator endpoints with a keycloak role. These endpoints are requested repeatedly (every 5 s) by an application called spring-boot-admin<https://github.com/codecentric/spring-boot-admin>. For the request spring-boot-admin obtains an AccessToken. Because there is a session for each request, we have thousands of open sessions for the service account of spring-boot-admin.
Any news, suggestions or solutions on avoiding these open sessions?
Thanks.
Jörg Zaunegger
-----Ursprüngliche Nachricht-----
Von: keycloak-user-bounces(a)lists.jboss.org<mailto:keycloak-user-bounces@lists.jboss.org> <keycloak-user-bounces(a)lists.jboss.org<mailto:keycloak-user-bounces@lists.jboss.org>> Im Auftrag von Pedro Igor Silva
Gesendet: Montag, 13. November 2017 09:52
An: keycloak-dev(a)lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
Betreff: RE: [keycloak-dev] Client and Service Account Session
Hi,
Currently, every time a confidential client tries to get a new access token
from the token endpoint a new session is created on the server. This can
lead to multiple active sessions for a single client/service account when
doing multiple requests to token endpoint.
To avoid that the client should store the access token/refresh token and
use a refresh token when appropriate in case the access token has expired.
That is fine.
Now, suppose a confidential client is deployed and wants an access token. A
new session will be created on the server. In case the application goes
down for some reason (e.g.: container moved to a different node in
kubernetes and without a persistent volume) and tries to get a new access
token, we may end-up with two active sessions when asking for a new token
after a re-deploy.
What are your thoughts about re-using existing sessions when doing client
credentials ? What could be the impact on clustering if we need (and we'll
probably need) to update the session ?
Another question would be ... Does make sense to also enable clients to
obtain tokens without necessarily creating a session on the server ? I
think that in most cases, you don't really want to keep track of sessions
when doing client credentials.
Regards.
Pedro Igor
7 years, 2 months
