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

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(a)lists.jboss.org [mailto:keycloak-user-bounces@lists.jboss.org] On Behalf Of Bill Burke Sent: Friday, August 21, 2015 6:19 PM To: keycloak-user(a)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(a)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(a)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(a)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.