[keycloak-dev] OTP API
Thomas Darimont
thomas.darimont at googlemail.com
Fri Nov 11 05:00:38 EST 2016
Hi Stian,
thanks for the feedback.I understand the philosophy behind not exposing
credentials to an application and agree that
one way to solve this is by using a custom endpoint.
Question: Is there a general recommendation or guideline about resource
names / paths? E.g. something like custom resources should be located
beneath a special base path (e.g. /custom) to avoid potential clashes with
Keycloak resources in newer versions?
I also like the idea for (partial) re-auth via some sort of popup / iframe.
Are there any JIRAs logged for this already?
Another thing is that this might not work in every case, e.g. when
integrating Desktop applications where a
the "client" sends the user credentials to a server which then needs to
check those credentials against keycloak, e.g. by trying to acquire an
access token.
Cheers,
Thomas
2016-11-11 8:48 GMT+01:00 Stian Thorgersen <sthorger at redhat.com>:
> This is not something we should add IMO. As Bill points out the whole idea
> is to not expose credentials to application. I'd rather see something that
> works without exposing credentials to the users. Could do a redirect with
> re-auth required. Could require just adding otp on re-auth. Could possibly
> do a popup with embedded login from KC. I'm sure there's cleaner ways than
> the applicaiton collection OTP.
>
> However, it's perfectly possible to implement this using a custom rest
> resource so if you really want it to do this then do it that way.
>
> On 10 November 2016 at 21:55, Thomas Darimont <thomas.darimont at googlemail.
> com> wrote:
>
>> Hello guys,
>>
>> I agree with you Bill that requiring a user to re-auth by redirecting to
>> the
>> auth-server is often the best thing to do.
>> However in business applications one often sees the requirement to
>> periodically
>> reauthenticate the user without requiring the user to login again (e.g.
>> without leaving the application).
>> A common example for this is that users need to reenter a OTP credential
>> before performing a certain critical operation...
>>
>> I gave this a quick spin...
>> https://github.com/thomasdarimont/keycloak/commit/e891ca604a
>> cf5fd494525092c7a88628d9fb20bd
>> as you can see I took some inspiration from the userinfo endpoint.
>>
>> Works quite well so far, but bruteforce protection is still missing.
>>
>> A demo session via curl looks like this:
>>
>> $ KC_REALM=otp-validation-test
>> KC_USERNAME=tester
>> KC_PASSWORD=test
>> KC_CLIENT=test-client
>> KC_CLIENT_SECRET=c57dc179-09bb-4bb7-9128-91b29dd7fc35
>> KC_URL="http://localhost:8081/auth"
>>
>> ## Request Tokens for credentials
>> KC_RESPONSE=$( \
>> curl -v \
>> -d "username=$KC_USERNAME" \
>> -d "password=$KC_PASSWORD" \
>> -d 'grant_type=password' \
>> -d "client_id=$KC_CLIENT" \
>> -d "client_secret=$KC_CLIENT_SECRET" \
>> "$KC_URL/realms/$KC_REALM/protocol/openid-connect/token" \
>> | jq .
>> )
>>
>> KC_ACCESS_TOKEN=$(echo $KC_RESPONSE| jq -r .access_token)
>> KC_ID_TOKEN=$(echo $KC_RESPONSE| jq -r .id_token)
>> KC_REFRESH_TOKEN=$(echo $KC_RESPONSE| jq -r .refresh_token)
>> * Trying 127.0.0.1...
>> % Total % Received % Xferd Average Speed Time Time Time
>> Current
>> Dload Upload Total Spent Left
>> Speed
>> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:--
>> 0* Connected to localhost (127.0.0.1) port 8081 (#0)
>> > POST /auth/realms/otp-validation-test/protocol/openid-connect/token
>> HTTP/1.1
>> > Host: localhost:8081
>> > User-Agent: curl/7.45.0
>> > Accept: */*
>> > Content-Length: 122
>> > Content-Type: application/x-www-form-urlencoded
>> >
>> } [122 bytes data]
>> * upload completely sent off: 122 out of 122 bytes
>> < HTTP/1.1 200 OK
>> < Connection: keep-alive
>> < Content-Type: application/json
>> < Content-Length: 3713
>> < Date: Thu, 10 Nov 2016 20:32:16 GMT
>> <
>> { [3713 bytes data]
>>
>> # We got an acces token ... now lets try to validate a wrong OTP code
>>
>> curl -v \
>> -H "Authorization: Bearer $KC_ACCESS_TOKEN" \
>> -H "Content-Type: application/json" \
>> -d '[{"type":"totp", "value":"24861"}]' \
>> $KC_URL/realms/$KC_REALM/credential-validation
>> * Trying 127.0.0.1...
>> * Connected to localhost (127.0.0.1) port 8081 (#0)
>> > POST /auth/realms/otp-validation-test/credential-validation HTTP/1.1
>> > Host: localhost:8081
>> > User-Agent: curl/7.45.0
>> > Accept: */*
>> > Authorization: Bearer eyJhb...EW3Q
>> > Content-Type: application/json
>> > Content-Length: 34
>> >
>> * upload completely sent off: 34 out of 34 bytes
>> < HTTP/1.1 400 Bad Request
>> < Connection: keep-alive
>> < Content-Length: 0
>> < Date: Thu, 10 Nov 2016 20:30:42 GMT
>> <
>> * Connection #0 to host localhost left intact
>>
>> # Let's try a currently valid OTP code
>>
>> curl -v \
>> -H "Authorization: Bearer $KC_ACCESS_TOKEN" \
>> -H "Content-Type: application/json" \
>> -d '[{"type":"totp", "value":"949784"}]' \
>> $KC_URL/realms/$KC_REALM/credential-validation
>> * Trying 127.0.0.1...
>> * Connected to localhost (127.0.0.1) port 8081 (#0)
>> > POST /auth/realms/otp-validation-test/credential-validation HTTP/1.1
>> > Host: localhost:8081
>> > User-Agent: curl/7.45.0
>> > Accept: */*
>> > Authorization: Bearer eyJhb...EW3Q
>> > Content-Type: application/json
>> > Content-Length: 35
>> >
>> * upload completely sent off: 35 out of 35 bytes
>> < HTTP/1.1 200 OK
>> < Connection: keep-alive
>> < Content-Length: 0
>> < Date: Thu, 10 Nov 2016 20:34:11 GMT
>> <
>> * Connection #0 to host localhost left intact
>>
>> Cheers,
>> Thomas
>>
>> 2016-11-10 14:27 GMT+01:00 Bill Burke <bburke at redhat.com>:
>>
>> > Should be generic and not specific to a credential type. Should also
>> > hook into brute force detection. IMO though, one of the reasons for SSO
>> > and keycloak is that the application does not gather credentials. This
>> > is the job of the auth server. IMO, we'd be better off with expiring
>> > the login at the client side, redirecting to auth server, auth server
>> > sees that the user session is 3 hours old, and requests OTP.
>> >
>> >
>> > On 11/10/16 7:52 AM, Thomas Darimont wrote:
>> > > Hello Rohith,
>> > >
>> > > not that I know of - we'd also like to have this functionality.
>> > >
>> > >
>> > > What would be the best place to add that? Perhaps this could be added
>> to
>> > > the UsersResource with a new
>> > > endpoint like "/users/{userId}/otp-validation" or a (new) dedicated
>> > > resource.
>> > >
>> > > A client could then do a POST to that endpoint with the current
>> user's
>> > > access token and the entered OTP code.
>> > > Keycloak could then lookup and check the provided otp code.
>> > > If the code is corret, response could indicate that via status HTTP
>> 200
>> > or
>> > > HTTP 400 otherwise.
>> > >
>> > > Cheers,
>> > > Thomas
>> > >
>> > > 2016-11-10 12:11 GMT+01:00 gambol <gambol99 at gmail.com>:
>> > >
>> > >> Hiya
>> > >>
>> > >> Does the latest version of Keycloak provide any means of verifying a
>> > user's
>> > >> TOTP?. Our use-case at the moment, we have an application which once
>> the
>> > >> user is authenticated we issue a token of sorts ... however, we wish
>> to
>> > >> provide a popup that requests a user's TOPT every few hours which we
>> > >> "could" verify via service account ... I can't see any access at the
>> > moment
>> > >> via the rest api
>> > >>
>> > >> Rohith
>> > >> _______________________________________________
>> > >> keycloak-dev mailing list
>> > >> keycloak-dev at lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> > >>
>> > > _______________________________________________
>> > > keycloak-dev mailing list
>> > > keycloak-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>> > _______________________________________________
>> > keycloak-dev mailing list
>> > keycloak-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> >
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
More information about the keycloak-dev
mailing list