Could anyone explain what would be the best approach for this scenario?: There are 2 separate Service Providers:

  1. System A is a server that works as a rest API for a mobile application.
  2. System B is a website which login is handled with simple and plain cookies.

I have read a lot and Ive found that the most used protocols in use right now for these kind of systems are SAML and OAuth, where OAuth works specially to give security to API services and SAML for web applications (cookie based).

Ideally, what is being looked for is a single log in, which is right now handled for System B through cookies in the main domain.

Is there a way to use both SAML and OAuth? Or What would be a good way to go?


So most application are going to use SAML or OAuth, not both. And SAML is a lot more involved than a simple cookie.

If your primary focus is authentication for multiple systems, and you don't have a federated auth provided in place today that will give you the infrastructure for SAML, I'd stick with OAuth, and if you need a authentication/profile provider that is more heavily specified than the bare OAuth spec, I'd look into OpenID Connect, which is a additional standard on top of OAuth 2.0.


First of all cookies don't act as SSO at all, they just improve user experience after sign-on. For SSO it's better to use SAML tokens.

One can always use both. In this scenario, the SAML Assertion can be used as an OAuth Bearer Token to access the protected resource. In addition, if the lack of authorisation is the only thing holding back on your OAuth implementation, be sure to check out OpenID and OpenID Connect, open standards that build upon OAuth in order to provide just that.

But I personally would not recommened to mix them for the same purpose.

It's a good idea to use different protocols for different scenarios. SAML is good for SSO with centralized identity store while OAuth is for API authorization. So, you may want to implement SSO and user authorization with SAML but you need to implement SAML infra acting as Identity Provider for all accounts (e.g. MS ADFS or Azure STS).

For mobile app authorization you'd better use OAuth with the corresponding app registered in Azure AD and having proper permissions in it.

REST API is supported by Azure AD; you may use Graph API as well to access it.

So anyway you need to invest to implement the identity store first.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.