I have a task on my hands, but not absolutely sure how to start on this.
Hopefully community can provide some guidance.
I need to integrate react-native mobile app with SAML thus enabling app to leverage SSO.
At the moment business have a desktop implementation which goes like this:
user goes to http://subdomain.example.com/
gets redirected to identity provider (IdP)
signs in at identity provider
gets redirected back to http://example.com
uses example.com SaaS as signed user.
I imagine a similar approach could be done for react-native app?
Or when it comes to SAML integration with react-native different pattern must be used?
Are there potentially 3rd party libraries?
Related
For the past few days, I have been wondering about the authentication issue in mobile applications. I am in the process of implementing a mobile application using React Native.
I'm also implementing an API for this application using .NET Core 6.0 technology and I'm trying to use OpenIdDict library.
One thing I can't understand: mobile applications nowadays when trying to login with login (mail/login/phone number) do not redirect to a separate login page, which should be hosted by an authorization server.
So how do apps use PKCE (if they use it at all)? Is it possible to implement PKCE without hosting such a page? Is it possible to implement an authentication server on the same server where the resources are available? Are two servers even necessary for the secure operation of such an application?
We have an auth infrastructure based on OAuth2 that is integrated into a variety of web apps within our organization. We also have a pure native application with no middle-ware of its own, and we want to integrate authentication into this native application. This application already has its own internal login mechanism with a native login screen, and we don't want to have it start launching external components like web browsers in order to display login windows. We are both the app provider and the auth provider, so the concern of the app having visibility into the user's credentials is less of an issue -- we trust ourselves to not intentionally do anything untoward with the user's credentials, and it's the same people writing a login form in the app as writing it on a web site. :-)
We are trying to figure out how best to support having the application continue to collect credentials the way it does now, but use them to obtain an auth token within our auth framework. With the APIs in place right now, the only way I can see for it to be done is to bake a Client Secret into the native app so that it can use a Resource Owner Password Credentials Grant request, since the code that would normally be making this call doesn't have a server side to live in. This feels really wrong, somehow. :-P
As far as I can see it, many of the structures of OAuth don't really apply to this app because it's not living in the context of a web browser, it doesn't have any concept of a "domain" nor any sort of "cross-domain" restrictions. It has been suggested that perhaps we create middleware for this app just for the purpose of exchanging authentication codes for tokens, but the rationale for that seems to be that this middleware theoretically ought to be able to somehow vet requests to determine whether they are legitimately from the application, and I don't see any way to do that that couldn't be faked by anyone with access to the client application code. Basically, the only purpose such middleware would serve would be to make the Client Secret irrelevant with respect to getting auth codes for credentials.
One thought that came to us was, how does something like Windows do it? Windows very obviously uses a native login form, but then some flow exists whereby the credentials that are entered are used for authentication and presumably, deep in the internals of the OS, for obtaining an auth token. Does anybody know if this architecture is documented anywhere? Does Microsoft's architectural choices here have any relation to OAuth2? What is the "best practice" for an application if you take it as a given that it doesn't have middleware and has its own native login form?
FWIW you don't need a client secret to use ROPC Grant to obtain or refresh tokens if the client is configured as a public client, i.e. a client that isn't capable of storing a secret.
RFC8252 OAuth 2.0 for Native Apps encourages using a native user agent for your scenario, using authorization code flows with PKCE. Authorization services like Okta and Auth0 have jumped onboard too, although they still recommend ROPC if the client is "absolutely trusted".
RFC6819 OAuth 2.0 Security discourages ROPC, but also says "Limit use of resource owner password credential grants to scenarios where the client application and the authorizing service are from the same organization", which are first-party apps.
So while the security verdict seems to be that authorization code+PKCE is the best practice, the UX hurdle of showing a user a browser window to log into a native app seem to be keeping ROPC alive. It's difficult to tell if that UX is jarring because people aren't used to it or because people can't get used to it.
I'm adding a login page for my mobile app, so that it integrates with Bluemix Single Sign On. I'm at the step to configure the Node.js app following the Bluemix Doc at Configuring a Node.js app. The example here about callback is for a web app. In the mobile app context, I don't have a redirect URL. So this code for example:
app.get('/auth/sso/callback',function(req,res,next) {...}
On the mobile client side, do I do a GET to /login?
I already have a login implemented using Mobile Client Access service. Is it something I can build up upon? For example,
app.post('/apps/:tenantId/:realmName/handleChallengeAnswer', function(req, res {...}
Can I call the Single Sign On API in here?
Thanks a lot for your help!
Jen
Is your mobile application based on nodejs? If so and you use a webview on your mobile application you could leave to the webview component to manage your authentication flow like working with a browser.
You instead have to manage authentication if your application is integrating with Rest APIs, in this case you could use SSO but your application has to manage cookies like a browser.
Bluemix Single Sign On so far has only been tested on web applications. I have no knowledge on whether Single Sign On would work smoothly on mobile applications.
Also, the Bluemix Single Sign On follows the OIDC protocol. So the redirect URL is a mandatory parameter when using the service, unfortunately.
Regarding building upon your login implementation, to my knowledge, it is not possible to include your implemented login in place of what is provided with the Single Sign On service. But you can choose to add the login implementation in addition to the login needed when using Single Sign On.
Hope that addresses your questions.
We have an Internet facing Web Application running, and recently our company made some agreements with a 3rd-party company which owns another web site. The idea is to provide access to this external web site to our current customers. Our users will click on an internal link in our solution which will open a new browser window with the third party site. User will not need to authenticate again in the 3rd party company site.
We have agreed to issue SAML2 tokens for our users, with a set of claims used by the 3rd-party site to query an present a personalized view to our users
Something important in our scenario is that users are already authenticated in our web site when they decide to access the 3rd-part web site.
What is the best way to implement all this?
I am thinking on implementing a custom-STS using the WIF SDK to generated those SAML2 tokens and pass then using HTTP POST (cookie) to the 3rd party site. If this is the right approach, then any pointers, tips?
Will ADFS make any difference?
Thanks for any help
Sounds like you'll be playing the role of Identity Provider - responsible for handling the "manual" authentication of the user and generating SAML responses to give the user SSO to the 3rd party website.
Implementing your own IdP is not trivial (there are a handful of specifications to understand), so unless you have your heart set on this as a development project, you may want to consider a COTS like Microsoft ADFS, PortalGuard (for whom I work) or Ping Identity.
Since you asked about ADFS specifically, it has native support for Active Directory as the user repository and has some interesting features with its claims transformation engine (if you get into a complex SP-IdP chaining scenario). Besides SAML it also supports WS-Federation which is important for integration with the other offerings in the Microsoft stack.
If your application is ASP.NET, then connect your application to ADFS.
So to get to your application, the user has to log in.
Then for the link to the 3rd party application use the IDP Initiated scenario (IdpInitiatedSignOnPage Class Overview). This sends a SAML2 token to the 3rd party application. ADFS will handle SSO for you.
To do this, you will have to configure the 3rd party application as a SAML one rather than a WS-Fed one.
My app is architected as follows: I have a web service (running on GAE, not very relevant to this question) and the data that this service contains is made available through a website and through mobile and desktop apps.
Currently, the user authenticates to the website via Google ClientLogin and the apps authenticate/get authorized via GAE's built-in oauth provider. (OAuth is being used here mostly for authentication, my app doesn't actually use any external data via OAuth other than the user's unique ID and email address.)
What I'd like to do is expand the number of services that users can use to login. Because of the complicating factor of the apps, it seems I need OAuth. But I can't really properly conceptualize how this flow should go.
Lets take Facebook as an example. When a mobile app goes through the Facebook oauth flow and acquires an access token, this isn't enough - because its my service, not the app, that actually needs to talk to facebook to retrieve contact info and a unique user ID. This leads me to think that the OAuth process needs to happen in the context of my service, and not the mobile app. My service then becomes the consumer and Facebook the oauth providor, and the service holds on to the oauth access token, this happens when a user sets up their account for the first time.
If this is the correct approach, where does that leave authentication for the apps? What happens when the user already has an account and installs a fresh instance of a mobile app? I imagine also going through the oauth process, matching up credentials with the data already stored by my service, and then issuing my own "access token" to the app from the service, to authorize that instance of the app. This seems convoluted and hackish.
I'm sure I can't be the only person who is in effect "borrowing" the account system of a third party for a mobile app with a backend, but I really don't see what the proper way to do this is.
What am I not seeing and/or getting conceptually wrong?
A few colleagues and I once did a project quite similar in nature, back in university. We authenticated our users through either Facebook or Foursquare, using their respective OAuth APIs.
The native Android version of the app opened up a WebView with the OAuth provider's start page, which redirected back to our service after authentication. Then our service did a request for the OAuth token from the OAuth provider (Foursquare has some pretty simple instructions). When we got that token, we set up a session using cookies, which we could access from the app.
To validate sessions, we just checked whether the access token was still valid with the provider. We also used the respective providers' unique user IDs to distinguish users.
So yes, what worked for us is: Make the app authenticate & authorise your service, not the app itself.