Office 365 Federated Authentication with WSO2 Identity Server Using OpenID Connect

In the scenario featured in this blog, we are going to try to login to a third party application using Office 365. WSO2 Identity Server is our Identity Provider.

Note: A big thanks goes to Dinali Rosemin Dabarera for her help and patience while this blog was being written.

Use Case

We need to secure web application and assure single sign-on feature while users are stored in federated a user store. In our case they are in Azure Active Directory.

The idea is to use an authentication hub that can provide federated authentication, like WSO2 Identity and Access Management (IAM). For Office 365 Federated authentication, we will need an Office 365 application. You’ll have to follow the steps below to create an Office 365 application.

Azure Setup

Go to Azure portal and click on Azure Active Directory in the left menu.

It will bring up the DefaultDirectory-Overview section where you can register a new application by clicking on New Registration.

New Registration Setup

In the Register an Application registration section, complete the following:

1. Name: newApp
2. Select Supported Account Types (the third option will give you the option to cover all organization directory and any personal Microsoft accounts)
3. Redirect URI: https://localhost:9443/commonauth
4. Click on Register

Once you will register, you will be redirected to an overview of your created application where you can find the client_id to create the Office 365 as the IDP in WSO2 Identity Server. In order to access this, select the Certificates & SecretsNew Client Secret.

In the Add a Client secret pop up, select the preferred duration and click Add.

Note: In the Clients secret section, you will see a newly created secret with the provided description. Once you leave this section the secret will be hidden and you cannot retrieve it, so be sure to save it immediately.

API Permission

By default the Microsoft Graph’s User.Read permission will be selected. Other permissions can be added by clicking on Add a Permission that will bring up a section to choose a specific API.

Once you have selected an API, you can select the delegated permission or Application permission that will bring different set permissions.

We can leave default for the purpose of federation authentication.

Grant Consent

In Grant Consent, click on Granting Admin Consent to grant all permissions.

Configure Manifest Setup of the Application

In manifest, edit groupMembershipClaims with possible values (All, SecurityGroup or none). To receive groups info in claims you need to choose All (to receive all groups) or SecurityGroup(to receive only security groups.

Note: if you leave the default value for groupMembershipClaims (which is “” — blank character), no group information will be propagated in a claim.

With all these configurations, we are good with Office365 side configurations. Now we have to move to WSO2 Identity Server side configurations.

WSO2 Setup

Configure Office365 as an Identity Provider

In WSO2 Identity Service, on the menu on the left side, choose IdentityProvides → Add Option to add an Add New Identity Provider section.

Basic Information Section

In the Basic Information section, only the name is mandatory so select a unique name.

Identity Provider Name: office365OpenID

Federated Authenticators Section

In the Federated Authenticator section, choose OAuth2/OpenID Connect Configuration.

Populate with the following:

• Enable OAuth2/OpenIDConnect Authenticator by clicking on the tick
• Client Id : d424e6d7-a43e-430b-b3b6–123d9a****** (value copied from Azure application, see New client secret setup)
• Client Secret: 5v6NC?.Dq=Nz=4lKZduZ3blY4uf***** (value copied from Azure application, see New client secret setup)
• Authorization Endpoint URL: https://login.microsoftonline.com/common/oauth2/authorize
• Token Endpoint URL: https://login.microsoftonline.com/common/oauth2/token
• Callback Url: https://localhost:9443/commonauth
• Additional Query Parameters : scope=openid

Claim Mapping

In the Claim Configuration section, setup userprincipal as a user id claim URI.

Role Mapping

In the Role Configuration section, setup the role mapping that you want to be defined to the federated user during the provisioning in the user store.

User groups that are coming from AD don’t have names in claims only GUID. These are all you have to do to create an office365 as IDP.

Configure Your Third-party Application as a Service Provider and Link Office365 as the Federated IDP

To set up this section you will need the application to be deployed and reachable. You can follow the Quick Start Guide so setup a sample application (https://docs.wso2.com/display/IS570/Quick+Start+Guide). Choose Scenario2.

In WSO2 Identity Service, on the menu on left side, choose Service Provides → Add Option to add a Add New Service Provider section.

1. Provide a unique name and click on Register

2. Inbound Authentication Configuration Section


Choose Oauth/OpenID Connect Configuration and click on Configure.



Populate callback URL and choose JWT token, leave the rest with default values. Callback Url: https://localhost.com:8080/pickup-manager/oauth2client. Choose JWT for the Token Issuer.



Click on Update.

3. Claim configuration

In order to get user details to the third party application, you need to configure all the claims as a requested claim. If you have any mandatory ones you can click on mandatory as well, but make sure that they are coming from the Office365 side.


4. Local and outbound authentication configuration

In the case of the simple federated option, you can choose Federated Authentication and select office365OpenID.

Now that we have finished setup configurations, we are now good to test the flow.

Test Workflow

I have chosen a third party app called pickup-manager in WSO2 Identity Server samples. In a browser type location of a deployed sample application that is secured by IS (in our case it is openID manager application)[PickUp Manager Login].

When you click on LOGIN, the application will be redirected to provide Office365 credentials.

Once when you successfully log in, you will be redirected back to the application.

Multi-step Authentication if Needed

In case of multi-step authentication, you can edit the Local & Outbound Authentication Configuration section in the service provide setup and choose Advanced Configuration where you can define different steps as displayed in this image.

After configuring this you can try the same flow then you should be able to see the WSO2 Identity Server login page first. Then once you successfully log in with that you will be redirected to the Office 365 to log in again with Office 365.