[keycloak-user] Authorization code flow without a browser

[Aikeaguinea]

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.
 
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.
 
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.
 
 
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.
>>
>>  --
>>  Aikeaguinea aikeaguinea at xsmail.com
>>
>>  --
>> http://www.fastmail.com - Same, same, but different...
>>
>>  _______________________________________________
>>  keycloak-user mailing list keycloak-user at lists.jboss.org
>>  https://lists.jboss.org/mailman/listinfo/keycloak-user
 
--
Aikeaguinea
aikeaguinea at xsmail.com
 
 

-- 
http://www.fastmail.com - Same, same, but different...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160428/044b692e/attachment.html