(Peter Pfläging)
SAML & OIDC on native mobile apps
Using standard IdP patterns (WebSSO) we have problems in native Apps on different devices: Re-login after certain amount of time Web redirect at logon not feasible in Mobile Applications Maybe no user interface? (Syncing of data for offline use!) 2 factor problems if you use the second factor
Possible solutions:
Login via Redirect and get a token from Service Provide (SP) Add a library which is able to logon as lib or service for your mobile device (login service) Use X.509 certs for login on your mobile Login on desktop, generate key in SP and type it in on mobile app (or scan QR code)
Drawbacks: What are you doing if your device is lost’? How usable are the solutions On what level is the binding? IdP SP Multiple IdP’s
Fyi: SURFnet had a SDK developed for secure usage of federated identity. You can read a blog about it at https://blog.surf.nl/en/secure-login-from-apps-surfconext/ . This SDK was developed before Google announced/released AppAuth ;-).
Blog related: https://insights.sei.cmu.edu/cert/2016/08/the-risks-of-google-sign-in-on-ios-devices.html
Peter: One of the centre points is how do we deal with mobile apps regarding identity provider environments In either SAML or OIDC the main principles are the same. Above are listed the different ways being used currently: 1. Web view - redirecting at logon which is not really feasible 2. Tokens 3. X.509 - certificates where you don’t have the problem of re-authentication
All of these are interactive logon-s . If i am using a certificate i use the same mechanism behind it bur with a REST service. With a X509 certificate the redirect is implicit without any input.
Peter S : Certificate usage for SAML IdPs does not connect to the native application itself though. There is no physical relation
Martin: We provide at IBM apps for mobile devices and the username or password gets often stolen in the app - enterprises on the other hand offer you certificates for user authentication. So the X 509 can be done via the application without an interface or with a normal interface
Peter: From a user’s view , on the certificate case there is no log on interface . On the protocol level between IdP and SP there is no difference between web view and certificate If we talk about the user interface, there is a large difference. Normally with the web view there is a log on screen and with the certificate the interface has no log on user.
Martin: We came to the topic by looking at a native app where in a setting menu you enter username or pass
Peter s : for local authentication ?
Martin: for the user yes. i have no chance though in my phone to enter a string of any kind.
Peter: The same mechanism of logging on is used for both native mobile app and web apps. One of the main problems with the solutions above is that in case of X509 is the certificate distribution
David: Suggestion - change the first point by password, meaning: Web view - redirecting at logon which is not really feasible - password - interactive
Peter S: I do not have any interest in the interface. That is the issue
Martin: most of my costumers now want SSO and they all implement saml and all that comes with it. IT works perfectly with web apps but the problem is in mobile apps. Am i missing something?
Peter s: yes the solution would be RFC 8252 RFC is of value because it details how to start a web view from your native app so that it does web SSO, with a conversion in between.
Peter: One of the main problems in the apps i have gotten is the renewal of information in the IdP side.
Peter s: that only matters once my service token expires
Peter: now i have the option where the token expires after 1 week and username pass need to be resent
Roland: depends if you’re using code flow or implicit flow.
Peter: letting it to time out is one of the only options right now because there is no real connection because of firewalls or other reasons between the sp and the back end idp
Peter s: the ideal scenario would be then using short lived tokens and let them refresh more often.
Martin: MDM - mobile device management is a real thing at the moment and it will live for a while longer
Peter: I believe it will not live long.
Peter s : SAML ECP on its own gives the client the possibility to be active in their own authentication process. it is basically SAML for web services. Microsoft apps for example do not talk SAML, there is a proxy in between and a federated protocol that keeps your password from leaking anywhere. The other case where you give the pass to the app not the proxy is also not good at handling passwords. Both cases worse than the other So if entering pass in the app itself is not okay, SAML ECP would be the solution.
Peter: To be real 99% of apps use web view. Apple has restricted the use of it, this being a good thing.
Peter 2: do you think is it possible to make the same thing with SAML artefact binding? The main point is that there is a url to address the application and possibly the artefact binding can it then be used, combined with the ideas behind RFC 8252?
Peter s: could be. In my community is not a workable thing because artefacts are not being used by us since we don’t have the problems that the artefact solves. They have operational limitations also. I agree it has its uses for sure but also its limitations. There are 2 things: the way you pass from the browser to the app and how to properly spin up an app view. Both these have not been applied yet in practice but i believe the process should be able to apply the same principles.
