Free Office 365 Single Sign-On without ADFS

Hopefully I have grabbed your attention with the title of this post.

One issue that many of my customers have when moving to Office 365, either as a stand-alone solution of as part of a hybrid – is how to ensure that end users have a seamless experience when navigating to their Office 365 environment.

There are a number of traditional approaches, such as DirSync which can offer the same login credentials to Office 365 – however short of caching these on the client side, this does not represent a true single sign on solution.

The other approach pitched to resolve this concern is the use of ADFS.  Some concerns with regards to the use of ADFS include:

  • Need for additional hardware (think of ADFS servers and an appropriate level of redundancy)
  • Configuration overhead for ADFS
  • Inflexibility to extend single sign on into additional applications without investing in more configuration overhead

Other solutions such as Azure AD Premium are not yet as mature as some third party alternatives such as Okta.

  • With Okta you can:
    Implement a free* single sign on solution (depending on edition)
  • Bypass Office 365’s home realm discovery and deliver users a true single sign on experience

The purpose of this blog post is to explore the second bullet above and configure Okta to automatically log your users into Office 365. I will intentionally avoid focusing on the setup of Okta itself.

Firstly, it’s worth exploring what the “out of the box” options provide us:

Option 1 – navigate to the Office 365 login page directly (

This is probably the default experience for many users.

It’s simple, however as Office 365 is a multi-tenanted solution – it relies on home realm discovery to understand whether your tenant is services by a single sign on solution (such as Okta) AFTER you have specified your login name.

Following the detection of your username, you are “automatically” logged in.

From a user perspective, if I have already logged into my machine – why should I have to type in my login to Office 365 again?

Option 2 – access the Okta home screen and click on the Office 365 icon

For those organisations who do not have an existing intranet, this is probably the recommended approach for many.

The benefits of this approach include the ability for users to easily see what cloud applications have been setup for them via Okta and to then access these as required.

The downside is that users need to remember to navigate to https://<tenant> or if pushed out as their homepage via group policy, be presented with a home screen that has limited branding potential.

Option 3 – embed a direct Office 365 Okta application link in another system e.g. a local intranet

Okta provides an “App Embed Link” for you to insert as a hyperlink in another application (e.g. from your intranet).

Whilst this provides some flexibility for most cloud applications, this can present an issue for Office 365 as you don’t necessarily want users to just login to “Office 365”, but most likely a specific team site e.g. https://<tenant>

Option 4 – smart links

Whilst some of these options present appropriate solutions for users, they either rely on changing behaviour or introducing additional clicks to the user journey.

I personally like option 4 as either stand along (or in conjunction with one of the other options above), this enables users to navigate to an Office 365 based intranet for example using existing URL’s such as

This also makes a migration from SharePoint On Premises to SharePoint Online for example more manageable as you can simply create a smart link against the existing on premises DNS entry to automatically redirect and log users into a new Office 365 based intranet.

The process

I utilised this blog for inspiration which gave me 95% of the answer:

However, the URL structure is slightly different now for both Office 365 and Okta.

I will reiterate the process end to end – this is straight from the link above.

1. Install Fiddler

Note that I found this to be the most reliable method as utilising network traffic monitoring with your web browser tools (e.g. Internet Explorer or Firefox) will typically clear the traffic information between pages as you are redirected

2. Open fiddler and enable HTTP descryption

3. Open Internet Explorer (I prefer in private browsing mode) and navigate to your Office 365 site e.g. https://<tenant>

4. Assuming that Okta is setup correctly for Office 365 already, you will be presented with the standard Office 365 login screen. Enter your domain username and hopefully you are redirected via Okta and logged in

It’s step #4 that we are trying to remove.

5. Open up fiddler and find the 302 redirection to your Okta host <tenant> which is prefixed by /app/office365<key>/sso/wsfed/passive?cbcxt=&popupui=&vv=&

6. Copy this URL (right click -> copy -> just Url and paste into Notepad<key>/sso/wsfed/passive?cbcxt=&popupui=&vv=&

7. Remove everything after wsfed/passive? And before wa=wsignin to create a base URL<key>/sso/wsfed/passive?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=wa%3Dwsignin1.0%26rpsnv%3D4%26ct%3D1421145006%26rver%3D6.1.6206.0%26wp%3DMBI%26wreply%3D

8. Double encode the desired smart link URL becomes

9. Now append your URL to the end of your base URL<key>/sso/wsfed/passive?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=wa%3Dwsignin1.0%26rpsnv%3D4%26ct%3D1421145006%26rver%3D6.1.6206.0%26wp%3DMBI%26wreply%3D

The above link if pasted in your browser will now automatically (in this example) log you into with Okta without the need to provide your login name to the Office 365 login portal.

You can now take this one step further and create the smart link for making this easier than the above for users to remember.

1. Create a DNS record for your desired “vanity” URL e.g. and point to a windows server

2. Within IIS create a new web site and enable the IIS redirection feature on your server if required

3. Ensure that this new site is setup with the above vanity URL and then create a new redirect through to your custom URL:<key>/sso/wsfed/passive?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=wa%3Dwsignin1.0%26rpsnv%3D4%26ct%3D1421145006%26rver%3D6.1.6206.0%26wp%3DMBI%26wreply%3D

The net result is that users can now navigate to and then be automatically logged into


Leave a Reply

Your email address will not be published. Required fields are marked *