As I understand it, using the authorization code flow rather than the implicit flow is recommended where possible. We have a server-side client application, but the user agents making requests are not browsers, but instead our own code. I'm not entirely sure how to make the authorization code flow work without a browser. For instance, if on the command line I request curl 'http://host:port/auth/realms/foo/protocol/openid-connect/auth?response_type=code&client_id=test-client&state=state&redirect_uri=http://www.example.com/hello-world' Then (assuming the parameters are correct) I get back an HTML login page with a form. In order to submit the credentials, I would need to dig the URL out of the action of the form and then submit a request like curl -X POST -d 'username=test-user' -d 'password=test1234' 'http://host:port/auth/realms/foo/login-actions/authenticate?code=Ctr79aRsbwPPkC4nEeT2vR9-TuC31uuXngQXoHQH6FE.ef26cfcd-a35b-4d1e-a4f7-49790f6e2f00&execution=a86f56da-9900-4f1d-a461-f18617a2333b' Three questions: 1. Is there some reason I shouldn't be trying to implement the authorization code flow like this? 2. Is there a way to get the proper login action back without having to dig it out of an HTML form? I've tried adding --header "Accept: application/json" to the command but this has no effect. 3. Is there a way of submitting credentials other than by using form parameters? I've tried HTTP basic auth but it doesn't work for me.

Yes, we could do this -- my impression though was that the auth code flow is considered more secure. (I admit I'm not entirely sure how the Keycloak implicit grant flow differs from direct access grants -- whenever I look at OAuth documentation it just mentions the explicit and implicit flows.) On Wed, Apr 27, 2016, at 12:14 PM, Bill Burke wrote: > Ues direct grants? > > On 4/27/2016 11:17 AM, Aikeaguinea wrote: > > As I understand it, using the authorization code flow rather than the > > implicit flow is recommended where possible. > > > > We have a server-side client application, but the user agents making > > requests are not browsers, but instead our own code. > > > > I'm not entirely sure how to make the authorization code flow work > > without a browser. For instance, if on the command line I request > > > > curl > > 'http://host:port /auth/realms/foo/protocol/openid-connect/auth?response_type=code&client_id=test-client&state=state&redirect_uri= http://www.example.com/hello-world' > > > > Then (assuming the parameters are correct) I get back an HTML login page > > with a form. In order to submit the credentials, I would need to dig the > > URL out of the action of the form and then submit a request like > > > > curl -X POST -d 'username=test-user' -d 'password=test1234' > > 'http://host:port /auth/realms/foo/login-actions/authenticate?code=Ctr79aRsbwPPkC4nEeT2vR9-TuC31uuXngQXoHQH6FE.ef26cfcd-a35b-4d1e-a4f7-49790f6e2f00&execution=a86f56da-9900-4f1d-a461-f18617a2333b' > > > > Three questions: > > 1. Is there some reason I shouldn't be trying to implement the > > authorization code flow like this? > > > > 2. Is there a way to get the proper login action back without having to > > dig it out of an HTML form? I've tried adding --header "Accept: > > application/json" to the command but this has no effect. > > > > 3. Is there a way of submitting credentials other than by using form > > parameters? I've tried HTTP basic auth but it doesn't work for me. > > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user -- Aikeaguinea aikeaguinea(a)xsmail.com -- http://www.fastmail.com - Access all of your messages and folders wherever you are _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

The answer depends on what your code is doing: a) Is it a server not invoking services on behalf of users, but rather on behalf of itself? Then use service accounts and you can also use public/private key based auth here (client credential flow from oauth2). b) Is it a user logging in through a non-browser based application? Then the ideal option if possible is to embed a web browser and use the authorization code flow. The alternative is to use direct grant (resource owner credential grant flow from oauth2). c) Is it a background process invoking a service on behalf of users when the users are not online? Then use offline tokens. On 27 April 2016 at 17:17, Aikeaguinea <aikeaguinea(a)xsmail.com&gt; wrote: > As I understand it, using the authorization code flow rather than the > implicit flow is recommended where possible. > > We have a server-side client application, but the user agents making > requests are not browsers, but instead our own code. > > I'm not entirely sure how to make the authorization code flow work > without a browser. For instance, if on the command line I request > > curl > ' > http://host:port/auth/realms/foo/protocol/openid-connect/auth?response_ty... > > Then (assuming the parameters are correct) I get back an HTML > login page > with a form. In order to submit the credentials, I would need to > dig the > URL out of the action of the form and then submit a request like > > curl -X POST -d 'username=test-user' -d 'password=test1234' > ' > http://host:port/auth/realms/foo/login-actions/authenticate?code=Ctr79aRs... > > Three questions: > 1. Is there some reason I shouldn't be trying to implement the > authorization code flow like this? > > 2. Is there a way to get the proper login action back without > having to > dig it out of an HTML form? I've tried adding --header "Accept: > application/json" to the command but this has no effect. > > 3. Is there a way of submitting credentials other than by using form > parameters? I've tried HTTP basic auth but it doesn't work for me. > > -- > Aikeaguinea aikeaguinea(a)xsmail.com > > -- > http://www.fastmail.com - Same, same, but different... > > _______________________________________________ > keycloak-user mailing list keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user

On 28 April 2016 at 17:53, Aikeaguinea <aikeaguinea(a)xsmail.com&gt; wrote: > __ > We have something of a special case. We have privileged devices for > which we will use service accounts and certificates/JWT based > authentication. > > Then we will have a user (employee of ours) perform a second log in > to the application running on the device. The particulars don't allow > us to use a browser in this instance. (For one thing, the user's > credentials are not a username/password -- I've had to create a > special authenticator for this purpose. But this isn't the only > reason.) So, to Brian's question, we are not embedding these > credentials in our code. That would normally be an argument for using a browser. Using an embedded browser allows you to enable different authentication modes in Keycloak without modifying your applications. Keycloak has built-in support for authentication Kerberos tickets for example, all without the applications knowledge. > > > Since the device is trusted, we could use the password credentials > grant. However, since this is a fairly high-security situation we'd > prefer not to be sending access tokens over the wire, particularly if > we're only relying on TLS for encrypting the token. If you're not sending access tokens over the wire, what are you sending over the wire? That's how Keycloak works and an access token is always going to be sent over the wire. Doesn't matter what flow you use. You can choose exactly what goes into the token though. > > > We could, on the other hand, use the authorization code flow--I'd > just have to follow the redirects and dig the form action out of the > form that's returned in the challenge page. I was just wondering if > there was some way to access that URL other than by chomping on the > HTML, e.g., by using a different "Accept:" header. The authorization code flows is by design a purely browser flow. Using this outside of the browser isn't the correct approach. The direct access grant (resource owner credentials) is the flow you want to use if you're not going to use a browser. > > > > On Thu, Apr 28, 2016, at 12:58 AM, Stian Thorgersen wrote: >> The answer depends on what your code is doing: >> >> a) Is it a server not invoking services on behalf of users, but >> rather on behalf of itself? Then use service accounts and you can >> also use public/private key based auth here (client credential >> flow from oauth2). >> b) Is it a user logging in through a non-browser based application? >> Then the ideal option if possible is to embed a web browser and >> use the authorization code flow. The alternative is to use direct >> grant (resource owner credential grant flow from oauth2). >> c) Is it a background process invoking a service on behalf of users >> when the users are not online? Then use offline tokens. >> >> On 27 April 2016 at 17:17, Aikeaguinea <aikeaguinea(a)xsmail.com&gt; >> wrote: >>> As I understand it, using the authorization code flow rather >>> than the >>> implicit flow is recommended where possible. >>> >>> We have a server-side client application, but the user agents >>> making >>> requests are not browsers, but instead our own code. >>> >>> I'm not entirely sure how to make the authorization code flow work >>> without a browser. For instance, if on the command line I request >>> >>> curl >>> ' >>> http://host:port/auth/realms/foo/protocol/openid-connect/auth?response_ty... >>> >>> Then (assuming the parameters are correct) I get back an HTML >>> login page >>> with a form. In order to submit the credentials, I would need to >>> dig the >>> URL out of the action of the form and then submit a request like >>> >>> curl -X POST -d 'username=test-user' -d 'password=test1234' >>> ' >>> http://host:port/auth/realms/foo/login-actions/authenticate?code=Ctr79aRs... >>> >>> Three questions: >>> 1. Is there some reason I shouldn't be trying to implement the >>> authorization code flow like this? >>> >>> 2. Is there a way to get the proper login action back without >>> having to >>> dig it out of an HTML form? I've tried adding --header "Accept: >>> application/json" to the command but this has no effect. >>> >>> 3. Is there a way of submitting credentials other than by using >>> form >>> parameters? I've tried HTTP basic auth but it doesn't work for me.

I should add that both the OAuth 2.0 spec and the OpenID Connect 1.0 spec indicate that the in the authorization code flow the access token is not revealed to the user agent (see RFC-6749 section 1.3.1 and Open ID Connect Core 1.0 at the top of section 3). Passing the access token to the user agent removes the security benefit of using this flow. Does Keycloak support a flow where the access token is not passed to the user agent? On Fri, Apr 29, 2016, at 01:58 PM, Aikeaguinea wrote: I understand that RFC-6749 only says that the user agent is typically a browser, but that's not a requirement of the spec. In this case, it isn't going to be. The security advantage of the authorization code flow is that the access token is transmitted directly to the client application without passing it through the resource owner's user agent. The request for the access token is made on the server side, and there is no requirement that the access token then be passed back to the user agent. Once the server validates the access token, it can consider the user's session as logged in and can associate that session with the permissions returned to it in the access token. If session state is held on the server, the user's session identifier then need contain no information about the user's ID and permissions; if the session information is maintained on the client side, the user's session token can be encrypted, which is not currently the case with Keycloak's signed JWT tokens. On Fri, Apr 29, 2016, at 12:13 AM, Stian Thorgersen wrote: On 28 April 2016 at 17:53, Aikeaguinea <aikeaguinea(a)xsmail.com&gt; wrote: We have something of a special case. We have privileged devices for which we will use service accounts and certificates/JWT based authentication. Then we will have a user (employee of ours) perform a second log in to the application running on the device. The particulars don't allow us to use a browser in this instance. (For one thing, the user's credentials are not a username/password -- I've had to create a special authenticator for this purpose. But this isn't the only reason.) So, to Brian's question, we are not embedding these credentials in our code. That would normally be an argument for using a browser. Using an embedded browser allows you to enable different authentication modes in Keycloak without modifying your applications. Keycloak has built-in support for authentication Kerberos tickets for example, all without the applications knowledge. Since the device is trusted, we could use the password credentials grant. However, since this is a fairly high-security situation we'd prefer not to be sending access tokens over the wire, particularly if we're only relying on TLS for encrypting the token. If you're not sending access tokens over the wire, what are you sending over the wire? That's how Keycloak works and an access token is always going to be sent over the wire. Doesn't matter what flow you use. You can choose exactly what goes into the token though. We could, on the other hand, use the authorization code flow--I'd just have to follow the redirects and dig the form action out of the form that's returned in the challenge page. I was just wondering if there was some way to access that URL other than by chomping on the HTML, e.g., by using a different "Accept:" header. The authorization code flows is by design a purely browser flow. Using this outside of the browser isn't the correct approach. The direct access grant (resource owner credentials) is the flow you want to use if you're not going to use a browser. On Thu, Apr 28, 2016, at 12:58 AM, Stian Thorgersen wrote: The answer depends on what your code is doing: a) Is it a server not invoking services on behalf of users, but rather on behalf of itself? Then use service accounts and you can also use public/private key based auth here (client credential flow from oauth2). b) Is it a user logging in through a non-browser based application? Then the ideal option if possible is to embed a web browser and use the authorization code flow. The alternative is to use direct grant (resource owner credential grant flow from oauth2). c) Is it a background process invoking a service on behalf of users when the users are not online? Then use offline tokens. On 27 April 2016 at 17:17, Aikeaguinea <aikeaguinea(a)xsmail.com&gt; wrote: As I understand it, using the authorization code flow rather than the implicit flow is recommended where possible. We have a server-side client application, but the user agents making requests are not browsers, but instead our own code. I'm not entirely sure how to make the authorization code flow work without a browser. For instance, if on the command line I request curl 'http://host:port /auth/realms/foo/protocol/openid-connect/auth?response_type=code&client_id=test-client&state=state&redirect_uri= http://www.example.com/hello-world' Then (assuming the parameters are correct) I get back an HTML login page with a form. In order to submit the credentials, I would need to dig the URL out of the action of the form and then submit a request like curl -X POST -d 'username=test-user' -d 'password=test1234' 'http://host:port /auth/realms/foo/login-actions/authenticate?code=Ctr79aRsbwPPkC4nEeT2vR9-TuC31uuXngQXoHQH6FE.ef26cfcd-a35b-4d1e-a4f7-49790f6e2f00&execution=a86f56da-9900-4f1d-a461-f18617a2333b' Three questions: 1. Is there some reason I shouldn't be trying to implement the authorization code flow like this? 2. Is there a way to get the proper login action back without having to dig it out of an HTML form? I've tried adding --header "Accept: application/json" to the command but this has no effect. 3. Is there a way of submitting credentials other than by using form parameters? I've tried HTTP basic auth but it doesn't work for me. -- http://www.fastmail.com - Send your email first class -- Aikeaguinea aikeaguinea(a)xsmail.com -- http://www.fastmail.com - A fast, anti-spam email service. _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user