Hi All, We're looking to start rolling the Keycloak OIDC flow out to some client-side Javascript applications, and I came across a question in coming up to speed on OIDC. You state in your docs <https://keycloak.gitbooks.io/securing-client-applications-guide/content/v... that the Javascript adapter is intended for client-side use: Keycloak comes with a client-side JavaScript library that can be used to > secure HTML5/JavaScript applications. > The docs also state that the default flow for this adapter is the Authorization Code flow: By default, the JavaScript adapter uses the Authorization Code > <http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth> flow. > However, the OIDC spec <http://openid.net/specs/openid-connect-core-1_0.html> says (section 3.1): ...The Authorization Code flow is suitable for Clients that can securely > maintain a Client Secret between themselves and the Authorization Server. > And again echoes the sentiment using the non-requisite MAY language in section 15.4: In general, it is up to Relying Parties which features they use when > interacting with OpenID Providers. However, some choices are dictated by > the nature of their OAuth Client, such as whether it is a Confidential > Client, capable of keeping secrets, in which case the Authorization Code > Flow may be appropriate, or whether it is a Public Client, for instance, a > User Agent Based Application or a statically registered Native Application, > in which case the Implicit Flow may be appropriate. > I'm aware that public clients who do not present a client secret are allowed under the OAuth spec <https://tools.ietf.org/html/rfc6749>;, and that these are often the type of javascript client that Keycloak sets up with the authorization code flow. What's more, I understand that the client secret is most commonly the reason cited for the client/server distinction with respect to flows. However, I was curious as to why the authorization code flow remains the default setting for Javascript applications. Isn't the refresh token also considered a form of a 'secret' since it's a long-lived mechanism whereby additional access/identity tokens can be retrieved? Why would the default setting *not* be implicit here? Could you help me understand why the authorization code flow was chosen as the default? Thanks in advance! Josh Cain | Software Applications Engineer *Identity and Access Management* *Red Hat* +1 843-737-1735 _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Thanks for the quick response Stian! Still getting my feet wet with OIDC, so please bear with me as I try to reconcile what I'm reading @ the spec with the Keycloak implementation. A few questions on your response: You say that it's 'usual' for these access tokens to have a long lifespan with implicit flow. How does that interact with the general guideline in section 16.18 of the spec when it says: Access Tokens might not be revocable by the Authorization Server. Access > Token lifetimes SHOULD therefore be kept to single use or very short > lifetimes. I would agree that a long-lived refresh token is indeed much preferred to doing something like extending the lifetime of an access token. However, is 'the OAuth redirect dance' the only alternative? I know that Keycloak's identity/session cookies will have been issued at this point - would it be possible to use something like an iFrame to refresh a short-lived access token?

Josh Cain | Software Applications Engineer *Identity and Access Management* *Red Hat* +1 843-737-1735 On Wed, Jul 13, 2016 at 1:37 AM, Stian Thorgersen <sthorger(a)redhat.com&gt; wrote: > With Implicit flow it's usual to have a long expiration on access tokens > as there is no refresh token. Once the access token is expired you're left > with having to do the whole OAuth redirect dance again to obtain a new > token. What's even worse is that if you have long lived access tokens > there's potentially a longer time between the verification of > the access token directly with Keycloak, which means that an access token > could potentially be used long after the session has been removed. > > With that in mind having short lived access tokens with a refresh token > is better in our opinion even for public clients. > > On 12 July 2016 at 19:22, Josh Cain <josh.cain(a)redhat.com&gt; wrote: > >> Hi All, >> >> We're looking to start rolling the Keycloak OIDC flow out to some >> client-side Javascript applications, and I came across a question in coming >> up to speed on OIDC. You state in your docs >> <https://keycloak.gitbooks.io/securing-client-applications-guide/content/v... >> that the Javascript adapter is intended for client-side use: >> >> Keycloak comes with a client-side JavaScript library that can be used to >>> secure HTML5/JavaScript applications. >>> >> >> The docs also state that the default flow for this adapter is the >> Authorization Code flow: >> >> By default, the JavaScript adapter uses the Authorization Code >>> <http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth> >>> flow. >>> >> >> However, the OIDC spec >> <http://openid.net/specs/openid-connect-core-1_0.html> says (section >> 3.1): >> >> ...The Authorization Code flow is suitable for Clients that can securely >>> maintain a Client Secret between themselves and the Authorization Server. >>> >> >> And again echoes the sentiment using the non-requisite MAY language in >> section 15.4: >> >> In general, it is up to Relying Parties which features they use when >>> interacting with OpenID Providers. However, some choices are dictated by >>> the nature of their OAuth Client, such as whether it is a Confidential >>> Client, capable of keeping secrets, in which case the Authorization Code >>> Flow may be appropriate, or whether it is a Public Client, for instance, a >>> User Agent Based Application or a statically registered Native Application, >>> in which case the Implicit Flow may be appropriate. >>> >> >> I'm aware that public clients who do not present a client secret are >> allowed under the OAuth spec <https://tools.ietf.org/html/rfc6749>;, and >> that these are often the type of javascript client that Keycloak sets up >> with the authorization code flow. What's more, I understand that the >> client secret is most commonly the reason cited for the client/server >> distinction with respect to flows. >> >> However, I was curious as to why the authorization code flow remains the >> default setting for Javascript applications. Isn't the refresh token also >> considered a form of a 'secret' since it's a long-lived mechanism whereby >> additional access/identity tokens can be retrieved? Why would the default >> setting *not* be implicit here? Could you help me understand why the >> authorization code flow was chosen as the default? >> >> Thanks in advance! >> >> Josh Cain | Software Applications Engineer >> *Identity and Access Management* >> *Red Hat* >> +1 843-737-1735 >> >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > >