http://shibboleth.1660669.n2.nabble.com/Android-Application-Question-td7630558.html Andrew: I'm working on prototype/proof of concept application for Android and iOS to showcase requiring users to authenticate/authorize against an existing Shibboleth implementation at a university. ------- Marc: I would use the system web browser (NOT an embedded one). This is the guidance Google uses for apps that authenticate with Google IDs and there are multiple other benefits. ------- Scott Cantor: As Marc said, the fact is that the system browser is really the way this is going. (...) Most apps like this use OAuth, which is to say they just reinvent cookies. They get it from the URL typically, or via some callback, and stash it off for use as a super-cookie. At least on Android I think they give you all this machinery for free now, and by using the system browser, you basically isolate the step of authenticating the user to the IdP to get the token, just like the non-mobile case. ------- Rainer hoerbe: The NAPPS (OpenID Native Apps SSO) WG is working on a standardized interface to a native token agent. This will move the responsibility for the native app to IDP interface to another place. In that context it is worthwhile to mention that there is an alternative emerging between system and embedded browsers: the web controller: https://developer.pingidentity.com/en/resources/napps-native-app-sso.html ------- scott: Unless I'm totally confused, AppAuth is not something the IdP supports or doesn't support, it's a detail of the mobile platform to mediate the browser interaction to improve the user experience. When you secure services with OAuth or cookies, you run an *SP* (in SAML parlance). The SP is the thing issuing the token(s) back to your application. It needs to authenticate the user. That's done with WebSSO and a browser, to interact with an IdP. The IdP is not issuing the tokens. If you don't want to operate a SAML SP, then you'd have a problem, but there are plenty of simple ways to do that if all you need to protect is a token issuing endpoint, the Shibboleth SP included. This whole thread is about the interactions between your app and the browser client. That is where all these new tricks come into play and the part that's rapidly evolving. ------- Marc: Just taking a quick look i think AppAuth will require OpenID Connect which Shib doesn't support The trick with AppAuth is that its relying on the 302 redirect you receive after the user authenticates to the OIDC IdP to redirect into your app instead of to a web server. So instead of the 302 being "https://mysp.mydomain.com/..." the redirect is "myregisteredapp://..." which tells the mobile device "this url is managed by my app, NOT the browser so open it there instead" at which point the app (which is using AppAuth) would complete the OIDC transaction by getting the id_token from the code_token in the response. ------- Andrew: I was thinking this morning that a decent approach might be to bounce the user to the system web app, have them log in and then have the web app "redirect" them to URL with an intent in it so that the phone would open the app again and pass a token/cookie value in that it could use to make API calls. (...) Let me back up a step... What I have is an existing web app (SAML SP, right?) that is currently set up to use the (Shibboleth) IdP and authn/authz its users. What I'd like to add to the mix is an android application that can make API calls to the web app but only if people are authenticated and authorized to do so. So the android app needs to present something to the SP like a browser would present cookies. If the user isn't authn/authz'd currently we'd open a browser, point it at the SP and complete the login flow (https://wiki.shibboleth.net/confluence/display/CONCEPT/FlowsAndConfig) but at the end of step 6 we'd issue another 302 to the Intent of the Android or iOS app to get them back into the native application... Andrew: Since I have more control over the SP than the IdP I was thinking of doing that redirect there, though. ------- scott: That is in effect just a gateway out of SAML into something else, yes. ------ Marc: OIDC: The 80/20 is pretty easy: 1. SP - Generate a nonce and redirect the user to authenticate 2. idp - auth & generate a OTP, redirect to SP 3. SP - validate nonce came back, use OTP and optional client secret to get an id_token via http post back channel call 4. SP - Optional - validate the id_token against the idp's public key 5. Do something useful now you know who's logged in it's really just artifact profile saml using JSON and JWT instead of XML Thats the 80/20 of OIDC at this point (as Scott states as well). Its pretty easy to build into your app and at this point most web server platforms support it (mod_auth_oidc for apache, asp.net has a couple of dozen implementations, java has several too).