How can I do Mobile App authentication with SAML IDP-CodePudding

We have a inhouse SAML2 Token based IDP. It works great with websites etc but we are building a new mobile app and since Mobile Apps dont play well with SAML, we are trying to put a Proxy Service Provider/Relying Party in between the MObile app and the IDP. The only function of the Proxy SP would be accept a SAML token and establish a session and then talk to the Mobile App using OpenID Connect. In the past we have used AWS cognito successfully with another client but we are moving away from AWS towards Azure and are wondering if Azure B2C is what we need to use for this. Does anyone have any experience with this or something similar. Specifically, Do we need to look into Azure AD or Azure AD B2c? It needs to be able to add an external Identity Provider (SAML Based) and receive the SAML token and redirect to a return url with the auth code. From there on its pretty straight forward with the OIDC flow.

TIA Mohan

CodePudding user response：

I'd recommend gradually moving towards an architecture with this behaviour:

APIs receive a JWT access token on every request and can use it to protect requests for data
Web and mobile clients authenticate users via OpenID Connect and an Authorization Server (AS), then receive an access token, so that they can call APIs
The AS issues tokens in a way that allows you to control scopes and claims issued in access tokens
The AS can integrate with various Identity Providers, including SAML ones

All of this allows you to code your apps with best capabilities, and first class support in all UI and API technology stacks. Azure AD is one example of an AS, and I would start by a spike to see if its SAML integration works for you.

The AS is an essential part of the architecture and not just a proxy. It is common to introduce one when moving from a web backend architecture (which only supports browser clients) to a web, mobile and API architecture.

The contents of the tokens are important also, since JWTs will identify users with a subject claim from the AS, not the SAML IDP. This may not work for your existing backend.

So all of this requires an architectural design. As an example, this detailed onboarding article describes common requirements, with a focus on being in control of your data.

An important consideration is to keep application code based on OAuth related standards. You should then be able to run your apps against any AS.