On 28 April 2016 at 17:53, Aikeaguinea <aikeaguinea(a)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(a)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(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
--
Aikeaguinea
aikeaguinea(a)xsmail.com
--
http://www.fastmail.com - Same, same, but different...