OAuth vs SSO: Which One Should I Use?

Currently, I am working on one project which provided me a lot of opportunities to learn about OAuth 2.0 and SAML and better understanding on which one to choose for SSO strategy.
I am choosing this topic because most of the people get confused between these two. While they have some similarities but they are very different too and to put it one line. I would say “OAuth is not Single Sign-On”

What is the difference between OAuth 2.0 and SSO?

OAuth (Open Authorization) is a standard for authorization of resources. It does not deal with authentication. It allows secure authorization in a simple and standard method from web, mobile and desktop applications.

If you try to log into Stack Overflow using Facebook, you’ll be redirected to Facebook’s website and will see something like the following:

Once authenticated with Facebook, it will ask for Stack Overflow’s permission to access your resources like your name, Email id, Profile picture and so on. This is an authorization request like what Stack Overflow can do and what cannot do?

SAML: Security Assertion Markup Language is an XML-based open standard data format for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. It is an umbrella standard that encompasses profiles, bindings and constructs to achieve Single Sign-On (SSO), Federation and Identity Management.

SSO is an authentication/authorization flow through which a user can log into multiple services using the same credentials.
For instance, at your company where we have various applications like leave application, lunch application, career application and so on and we can configure all these applications to one Active Directory for authentication. Another example can be Atlassian account where you once logged in can use their other applications like Bamboo, JIRA, Confluence and so on.

Both examples represent SSO.

One of the main benefits to using SSO is that your users have only a single account and password to remember which gets them into all of their services.

Conclusion: When Should I Use Which?

• If your use case requires a single account to log into many applications, then go with SSO like your internal company applications.
• If your use case involves providing access (temporarily or permanent) to resources (such as accounts, pictures, files etc.), then use OAuth.
• If your use case requires a centralized identity source, then use SSO.
• If your case requires to have accounts on many different services, and selectively grant access to various services, use OAuth

Set up Shibboleth SP as a SAML 2.0 service provider with G Suite

Prerequisite:

1. Basic understanding of SAML 2.0, SSO and Shibboleth SP.  
2. SP setup up and working on your instance.
3. Must having administrator account to register your SP on G suite

G Suite setup:

• Login to https://admin.google.com using your administrator account.
• Click Security > Set up single sign-on (SSO)
• Click the Download button to download the Google IdP metadata and the X.509 Certificate
• Now click on Apps > SAML apps.
• Select the Add a service/App to your domain link or click the plus (+) icon in the bottom corner. The Enable SSO for SAML Application window opens.
• Click SET UP MY OWN CUSTOM APP
• We have already downloaded the certificate and Idp Metadata, click NEXT
• On the Basic application information window, Enter the Application name and Description values.
• In the Service Provider Details section, enter the following URLs into the Entity ID, ACS URL, and Start URL Fields:

1. ACS URL: https://your-domain-name.com/Shibboleth.sso/SAML2/POST
2. Entity ID: your-domain-name.com/shibboleth
3. Start URL: https://your-domain-name.com/app

Note: You can get the ACS URL and entityID by hitting https://your-domain-name/Shibboleth.sso/Metdata. It will download the Shibboleth SP metadata file containing all the URLs like entityID in the first few lines and ACS URL which is nothing but AssertionConsumerService URL having SAML 2.0 HTTP-POST binding.

    <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://your-domain-name.com/Shibboleth.sso/SAML2/POST" index="10"/>

• Leave Signed Response unchecked. When the Signed Response checkbox is unchecked, only the assertion is signed. When the Signed Response checkbox is checked, the entire response is signed.
• The default Name ID is the primary email and select EMAIL as Name ID Format.
• Click Add NEW MAPPING and then add EMAIL and choose Basic information and Email from 2^nd and 3^rd drop down list.
• Click Finish.
• Now go to again on Apps -> SAML apps and select your APPLICATION.
•  At the top of the gray box, click More and choose:

1. 1. On for everyone to turn on the service for all users (click again to confirm).
   2. Off to turn off the service for all users (click again to confirm).
   3. On for some organizations to change the setting only for some users.
      

Configured G Suite details in your Shibboleth SP

• Drop the downloaded Google Idp metadata to opt\shibboleth-sp\etc\shibboleth directory.
• Open Shibboleth2.xml file and add below snippet
  • <MetadataProvider type="XML" file="C:\opt\shibboleth-sp\etc\shibboleth\<GOOGLE_IDP_FILENAMExml>"/>    

• Restart Shibboleth.

 Verify that SSO between G Suite and Zendesk is working

• Close all browser windows.
• Open https://your-domain-name.com/app and attempt to sign in.
• You should be automatically redirected to the G Suite sign-in page or if you are having discovery page then it will come under drop down menu
• Enter your sign-in credentials.
• After your sign-in credentials are authenticated you're automatically redirected back to your Application.

Happy coding..!!!

Singleton Class Vs Singleton bean scope

I have seen people getting confused between singleton scope vs singleton design pattern. Basically, there is a bit difference between these two.

Singleton scope: The spring support five different scopes and it is used to decide which type of bean instance should be returning from Spring container back to the caller. One of the scope is Singleton and the by default scope too. It returns a single bean instance per Spring IoC container.

<bean id=”object1” class=“com.package.classname”/>

When I said, single bean instance per spring Ioc Container i.e. you will always get the same object regardless of the number of call of the same bean but if you declare another bean for the same class then you will get another object for another bean.

Let’s understand this with an example:

<bean id=”object1” class=“com.package.classname”/>

<bean id=”object2” class=“com.package.classname” scope=”prototype”/>

<bean id=”object3” class=“com.package.classname”/>

ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(APP_FILE);

Classname name1 = (Classname) context.getBean(“object1”);

Classname name2 = (Classname) context.getBean(“object2”);

Classname name3 = (Classname) context.getBean(“object3”);

name1==name1 // true, object1 is singleton, calling again n again will give the same object.

name2==name2 //false, object2 is prototype, calling again n again will give the different object

name1==name3 // false, object1 & object3 is singleton but two different bean.

So, the question arise how will you achieve the Singleton design pattern in Spring?

Spring framework provides facility to inject bean using factory method i.e. that returns an instance of its own class and can be used in singleton design pattern.

public class Singleton {

         

                private static volatile Singleton instance = null;

                private Singleton(){        

                }

                                public static Singleton  getInstance(){

                                if(instance == null) {

                                                synchronized (Singleton.class) {

                                                                if(instance == null){

                                                                                instance = new Singleton();

                                                                }

                                                }

                                }

                                return instance;

                }

           }

<bean id="object4" class="com.package.Singleton" factory-method="getInstance"/>

       <bean id="object5" class="com.package.Singleton" factory-method="getInstance"/>

Singleton singleton1= (Singleton) context.getBean(“object4”);
Singleton singleton2= (Singleton) context.getBean(“object5”);

singleton1==singleton1 // true, object1 has singleton scope, calling again n again will give the same object.

singleton1==singleton2 //true, Class is a singleton and we are getting an object from getInstance using factory-method.

Conclusion: Singleton scope is a bit different from a single design pattern, Returns a single bean per Spring Ioc Container whereas singleton design pattern will always return the same object.

Singleton scope can be useful where you are creating multiple datasource in your application where each datasource point to a different object.

You can download the code source from my GitHub repository.

Happy coding!!!