[keycloak-user] HMAC and its implementation for a mobile app

[Bill Burke]

Why would Keycloak be involved?  Keycloak is an authentication server. 
What you're describing sounds like an application specific thing.

On 8/21/2015 8:59 AM, Mohan.Radhakrishnan at cognizant.com wrote:
> I understand that you are describing the OAuth flow ?
>
> But in this case a message digest of the mobile device app's configuration parameters are sent from the server. They are going to be hashed using SHA-256 and something like HMAC.  So the shared secret
> Should be present on the server and the device.
>
> The device needs to ask  KeyCloak for a shared HMAC secret. Does this seem a valid scenario ?
>
> Thanks,
> Mohan
>
> -----Original Message-----
> From: keycloak-user-bounces at lists.jboss.org [mailto:keycloak-user-bounces at lists.jboss.org] On Behalf Of Bill Burke
> Sent: Friday, August 21, 2015 6:19 PM
> To: keycloak-user at lists.jboss.org
> Subject: Re: [keycloak-user] HMAC and its implementation for a mobile app
>
> OAuth, OpenID Connect, and SAML clients do not require a client secret or a keypair.  By client I mean "device" not "user".  A client credential is only needed if the realm/application is very sensitive about which devices it trusts.
>
>
> For mobile, there are 2 ways I'm familiar with (not sure how Cordova fits in) to do a login
>
> 1) Do the Oauth/OpenID dance (oauth code flow) with redirects between your mobile app and your mobile device's browser.  Credentials are entered in the HTML pages returned from the keycloak server.  In other words, this is just a normal web login.  Both Android and iOS support URI redirects. This dance ends with the mobile device having a temporary token and a refresh token.
>
>
> 2) The mobile app gathers the credentials and makes a REST invocation to Keycloak to obtain a temporary token and a refresh token.
>
> Once the device has a token it just transmits it with its HTTP requests to whatever services it is invoking on.
>
> Hope that answers your question.
>
>
> On 8/21/2015 2:15 AM, Mohan.Radhakrishnan at cognizant.com wrote:
>> Hi,
>>
>>           This is just a general question about HMAC and its
>> implementation for a mobile app. The backend is a set of layers and
>> one of it is a WebSphere Broker that has to send a message digest of
>> JSON data. In order to ensure both data integrity and authenticity we
>> also need a shared secret. This means that we need to distribute the
>> shared key and store it somewhere. What do keycloak users use for this scenario ?
>>
>> Does the Android mobile app. Request for a shared key which the
>> backend also knows(like what the AWS REST flow does) ? How is this done ?
>>
>> If we want to use digital signatures then the apps. Need one part of a
>> keypair. How can we distribute and share the public keys ? We don't have
>>    any requirement for OAuth.
>>
>> Thanks,
>>
>> Mohan
>>
>> This e-mail and any files transmitted with it are for the sole use of
>> the intended recipient(s) and may contain confidential and privileged
>> information. If you are not the intended recipient(s), please reply to
>> the sender and destroy all copies of the original message. Any
>> unauthorized review, use, disclosure, dissemination, forwarding,
>> printing or copying of this email, and/or any action taken in reliance
>> on the contents of this e-mail is strictly prohibited and may be
>> unlawful. Where permitted by applicable law, this e-mail and other
>> e-mail communications sent to and from Cognizant e-mail addresses may
>> be monitored.
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> 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
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored.
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com