[keycloak-user] Disabling status cookie
Marek Posolda
mposolda at redhat.com
Wed Feb 17 16:00:14 EST 2016
Looks we already support it? When you go in admin console to
"Authentication" and then choose flow "Direct grant", you can see that
OTP authenticator is there and it's optional by default (not sure if you
accidentally change it to REQUIRED based on your errors).
The possibilities are:
- Add parameter "totp" to the direct grant request together with
username and password (For example
username=sarp&password=pass1234&totp=123456&grant_type=password&client_id=admin-cli
)
- Disable OTP Authenticator for the direct grants flow (just if you
don't have a way to ask user for TOTP in your app).
Marek
On 17/02/16 17:04, Stian Thorgersen wrote:
> You can't get the token using direct grant if totp is enabled. We will
> have to add this at some point. Feel free to create a JIRA for it.
>
> On 17 February 2016 at 15:39, Sarp Kaya <akaya at expedia.com
> <mailto:akaya at expedia.com>> wrote:
>
> My issue is not "Account is not fully set up” error, I can
> “afford” to set it up through the web ui. The problem is after
> setting it up the curl that I give does not grant me a token and
> gives “Invalid user credentials” error, despite the fact that
> username and password are correct.
> So my question is whether it is possible to get the token using
> "/auth/realms/{realms}/protocol/openid-connect/token
> <http://localhost:8080/auth/realms/demo/protocol/openid-connect/token>”
> or similar API when the account itself has TOTP enabled (and
> configured)?
>
> From: Bruno Oliveira <bruno at abstractj.org
> <mailto:bruno at abstractj.org>>
> Date: Wednesday, February 17, 2016 at 8:01 PM
> To: Abdullah Sarp Kaya <akaya at expedia.com
> <mailto:akaya at expedia.com>>, Bill Burke <bburke at redhat.com
> <mailto:bburke at redhat.com>>, "keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>"
> <keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>>
>
> Subject: Re: [keycloak-user] Disabling status cookie
>
> I believe that Stian recently replied here
> http://lists.jboss.org/pipermail/keycloak-user/2016-January/004484.html
>
>
> On Wed, Feb 17, 2016 at 3:55 AM Sarp Kaya <akaya at expedia.com
> <mailto:akaya at expedia.com>> wrote:
>
> Thanks for the suggestion. It works just as expected. I was
> also wondering how would direct grant API use TOTP? I tried
> using it, before configuring I received
> {"error_description":"Account is not fully set
> up","error":"invalid_grant"} however after setting the
> account I kept getting {"error_description":"Invalid user
> credentials","error":"invalid_grant"} this is how I requested:
>
> curl -X POST
> 'http://localhost:8080/auth/realms/demo/protocol/openid-connect/token'
> --data
> 'username=sarp&password=pass1234&grant_type=password&client_id=admin-cli'
> -v
>
> Have I done something incorrect when requesting for a token?
>
> From: <keycloak-user-bounces at lists.jboss.org
> <mailto:keycloak-user-bounces at lists.jboss.org>> on behalf of
> Bill Burke <bburke at redhat.com <mailto:bburke at redhat.com>>
> Date: Tuesday, February 16, 2016 at 10:38 PM
> To: "keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>"
> <keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>>
> Subject: Re: [keycloak-user] Disabling status cookie
>
> See our direct grant API. Here's an example:
>
> https://github.com/keycloak/keycloak/blob/master/examples/demo-template/admin-access-app/src/main/java/org/keycloak/example/AdminClient.java
>
> I *STRONGLY* suggest you do not use the direct grant API for
> browser-based applications. Otherwise you lose 90% of the
> features of Keycloak. Use the direct grant API for REST
> clients, that's what it was designed for.
>
> On 2/16/2016 1:59 AM, Sarp Kaya wrote:
>> Hello,
>>
>> I want my users to be able to login via API calls with our
>> without requiring a browser. I looked at examples and found
>> customer-app-cli, however I realised that even with manual
>> login, the current workflow requires a browser to login. I
>> found that every time when
>> http://localhost:8080/auth/realms/demo/protocol/openid-connect/auth?response_type=code&client_id=customer-portal-cli&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
>>
>> this page loads we get a form with a different code. In
>> theory we should be able to just stick username and password
>> in the body and be able to get 302 response. However when I
>> get the curl equivalent of what browser is doing I’ve gotten
>> the below:
>>
>> curl
>> 'http://localhost:8080/auth/realms/demo/login-actions/authenticate?code=oY8nS7rFOlwYHNJwWS6kcw88jbxluo8EuDmZ_o5TWsw.431db3e8-6234-4ba5-8818-ed0335b8ee72&execution=08d88824-1286-4455-b5d1-07240bda8efd'
>> -H 'Cookie:
>> KEYCLOAK_STATE_CHECKER=a2teB_8_wfAfD9VtmV0DJhqDEuM9187r58mVW24Gfrg;
>> KC_RESTART=eyJhbGciOiJIUzI1NiJ9.eyJjcyI6IjQzMWRiM2U4LTYyMzQtNGJhNS04ODE4LWVkMDMzNWI4ZWU3MiIsImNpZCI6ImN1c3RvbWVyLXBvcnRhbC1jbGkiLCJwdHkiOiJvcGVuaWQtY29ubmVjdCIsInJ1cmkiOiJodHRwOi8vbG9jYWxob3N0OjgwODAvYXV0aC9yZWFsbXMvZGVtby9wcm90b2NvbC9vcGVuaWQtY29ubmVjdC9vYXV0aC9vb2IiLCJhY3QiOiJBVVRIRU5USUNBVEUiLCJub3RlcyI6eyJhY3Rpb25fa2V5IjoiYTA1MzFlNTYtZjk0Zi00NmM4LWFlNGUtNjQ4MDUyNDc2ZjEwIiwiYXV0aF90eXBlIjoiY29kZSIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4MC9hdXRoL3JlYWxtcy9kZW1vIiwicmVzcG9uc2VfdHlwZSI6ImNvZGUiLCJyZWRpcmVjdF91cmkiOiJ1cm46aWV0Zjp3ZzpvYXV0aDoyLjA6b29iIn19.B5vuMj-fafRAS0gJ6m-OrU5cX0atABuWy252y5k7jr0'
>> -H 'Origin: http://localhost:8080' -H 'Accept-Encoding: gzip,
>> deflate' -H 'Accept-Language: en-US,en;q=0.8' -H
>> 'Upgrade-Insecure-Requests: 1' -H 'User-Agent: Mozilla/5.0
>> (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36
>> (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36' -H
>> 'Content-Type: application/x-www-form-urlencoded' -H 'Accept:
>> text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8'
>> -H 'Cache-Control: max-age=0' -H 'Referer:
>> http://localhost:8080/auth/realms/demo/protocol/openid-connect/auth?response_type=code&client_id=customer-portal-cli&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob'
>> -H 'Connection: keep-alive' --data
>> 'username=sarp&password=pass1234&login=Log+in' —compressed
>>
>> I was hoping not to use the cookies and just change the code
>> bit with a new request to the page mentioned above and expect
>> 302 response, however I am getting 500 responses saying error
>> occurred instead.
>>
>> I looked on admin management console, but could not really
>> find a way to disable cookies for the given client or the
>> realm. I am guessing that one of those cookies are encrypting
>> something that is required and not using it simply prevents
>> logging in successfully. So how can I disable this requirement?
>>
>> Kind Regards,
>> Sarp Kaya
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> <mailto:keycloak-user at lists.jboss.org>https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
> _______________________________________________
> 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/20160217/8b1493fa/attachment-0001.html
More information about the keycloak-user
mailing list