By: Camil Sumodhee user 02 Mar 2016 at 1:21 p.m. CST

6 Responses
Camil Sumodhee gravatar
We are trying to use OIDC to enroll and manage users, and UMA to protect our backend APIs. Our OAuth client is a mobile application that uses Google to authenticate the user in the mobile app. This process happens only between the mobile app, the user and Google. Gluu is not involved at this stage. The outcome of this process is a Google id_token stored in the mobile app. Our idea is to use OIDC implicit flow with Gluu to enroll that user. 1. The mobile app would pass the following to Gluu in a single request: client_id, scope, redirect_uri and the Google id_token to an endpoint (which one?) 2. the Google id_token would be verified by a custom script. If the id_token is valid, create a new user (if he doesn't exist) and authenticate him in Gluu (same logic as gplus custom script). 3. return a Gluu id_token and access_token (with attributes uma_authorize) to the mobile app. We have managed to create an OIDC client profile with the correct scopes, get an AAT token (with basic authentication not Google) and we have tested the whole UMA flow successfully. But we can't find a way to use the custom scripts properly. This where we are stuck: 1. We don't have the need for a login form. (such as gpluslogin.xhtml). We only need an endpoint to post the parameters (scope, client_id, google id_token). Is there a way to customize this? 2. Then assuming we solved #1 we want to trigger the execution of a custom script that would validate the google id_token, enroll a new user and authenticate existing ones (like gplus custom script). 3. If #2 returns True, how do we manage to return the tokens defined in our Gluu OIDC client profile? Thanks in advance for your help!

By Aliaksandr Samuseu staff 02 Mar 2016 at 1:43 p.m. CST

Aliaksandr Samuseu gravatar
That's an interesting approach. Why don't you want to implement some very simplistic login screen containing only a form with a serveral hidden fields, which your application will first request, and then auto-submit all your parameters to custom authentication script using the form? Not sure is it feasible though, let me redirect your question to senior technician.

By Aliaksandr Samuseu staff 02 Mar 2016 at 1:47 p.m. CST

Aliaksandr Samuseu gravatar
Camil, I've edited your post a bit to make it more readable (mark up at our boards can be not so intuitive sometimes)

By Camil Sumodhee user 02 Mar 2016 at 3:29 p.m. CST

Camil Sumodhee gravatar
Hi Aliaksandr, Thanks for editing my post... My bad, I had missed the nice "Preview" button. The reason why we don't want to call a form is: - In our mobile application we're able to provide a much better user experience by doing "native" integration of our app with 3rd parties SDKs (that includes Google, Facebook etc... as external identity providers). Showing even a simple login screen is not an option actually. - If I'm not mistaken, the same login screen is being used to login our IT admin (that will be managing our Gluu instances), and our app "users". Ideally we would like to have a different client profile for separation of concerns. Cheers.

By Michael Schwartz Account Admin 02 Mar 2016 at 3:39 p.m. CST

Michael Schwartz gravatar
Camil, You should review: [OAuth 2.0 for Native Apps](https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-02) Using the system browser is better for security. Implicit flow should only be used for javascript applications. In any case, I think using a specific authentication script should be possible if you specify `acr_values` in the request, and make sure to specify "native" as the "Usage Type" in the authn custom script form in oxTrust. If this does not work, please post here.

By Camil Sumodhee user 03 Mar 2016 at 2:02 a.m. CST

Camil Sumodhee gravatar
Thanks for the prompt reply. We'll review this and let you know how things go.

By Aliaksandr Samuseu staff 03 Mar 2016 at 9:04 a.m. CST

Aliaksandr Samuseu gravatar
Hi, Camil. You should listen to Mike's advices, using `acr_values` parameter is the way to ask Gluu to use specific auth method. I just wanted to make clear my statement (it seems you get it wrong a bit): >In our mobile application we're able to provide a much better user experience by doing "native" integration of our app with 3rd parties SDKs (that includes Google, Facebook etc... as external identity providers). Showing even a simple login screen is not an option actually. >If I'm not mistaken, the same login screen is being used to login our IT admin (that will be managing our Gluu instances), and our app "users". Ideally we would like to have a different client profile for separation of concerns. No problems here, you can still do all of these. First, you may create custom login pages for each script (and steps of the script). Then you may select a specific script with `acr_values` parameter as Mike suggested. Second, my point was that your native app could silently download some simplistic login page with a singe login form, put all parameters you need in the form's fields, then submit it behind the scene to your custom auth script for processing. You don't need to show this page to a user.