[keycloak-user] Authorization code flow without a browser

[Brian Cook]

In auth code flow the authorization code is passed back as a URL parameter
to the redirect uri. The oauth client then uses the client ID, secret and
auth code to request the access token.  I think the confusion was you said
'over the wire'.  The access code is transmitted over the wire but not to
the user agent.

-Brian
On May 2, 2016 7:02 AM, "Aikeaguinea" <aikeaguinea at xsmail.com> wrote:

> 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 at xsmail.com> 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 at xsmail.com> 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 at xsmail.com
>
>
>
>
> -- http://www.fastmail.com - A fast, anti-spam email service.
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160502/8bd48496/attachment.html