fusionauth-issues
fusionauth-issues copied to clipboard
Feature: Login with Microsoft
Login with Microsoft
Problem
The problem is I can't login to FusionAuth with Microsoft. :-)
Solution
Add the ability to login with Microsoft.
Alternatives/workarounds
It seems that Microsoft also supports OpenID Connect, so this may work today using the generic OpenID Connect identity provider. https://fusionauth.io/docs/v1/tech/identity-providers/openid-connect
Additional context
https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-openid-connect-code
How to vote
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.
This should work out of the box using OpenID Connect, but it seems the OpenID connect itself may not work properly?
I've been testing, intercepting the token endpoint, and confirmed that FusionAuth's request body specifies client_id=...&code=...&grant_type=authorization_code&redirect_uri=...
client_secret is obviously missing, and Azure AD consequently fails and points this out:
AADSTS7000218: The request body must contain the following parameter: 'client_assertion' or 'client_secret'
Both client_secret_basic
is supported client_secret_post
, according to Microsoft's documentation, if that makes any difference in resolving this.
Hi @gnab thanks for taking the time to report this issue. Yes, in theory - this should work out of the box if your AD supports OIDC.
This is a known issue, and it has been fixed in 1.6.0
which should be out yet this week.
We don't currently have a way for you to specify in the OIDC configuration within FusionAuth to use client_secret_basic
or client_secret_post
. But in theory client_secret_basic
is the lowest common denominator, so that is what we send.
Being able to authenticate with Azure AD and/or ADFS would be key for us; is the only way to achieve this through OpenID?
OpenID is an option, in version 1.6.0, we will also support SAML federation. I believe the Azure AD may only be supporting OpenID Connect.
https://github.com/FusionAuth/fusionauth-issues/issues/104 https://fusionauth.io/docs/v1/tech/release-notes/
This should now work with the OpenID Connect IdP in version 1.6.0, if you run into issues, open a bug. Thanks!
Can we close this issue, @robotdan ?
We could, I initially opened this to add a full typed integration for "Login with Microsoft" such as described here : https://docs.microsoft.com/en-us/azure/active-directory/develop/tutorial-v2-asp-webapp
But you can in most cases "sign in with Microsoft" via OpenID Connect, or SAML v2. I don't know how many people would "sign in with Microsoft" in a similar sense to Twitter, Facebook or Google.
Came up on a customer call.
We could document the OIDC implementation in our docs, or build a full Microsoft 365/Azure style IdP. In 1.28.0, we delivered Xbox and the integration will be nearly identical. So if we think it is valuable to have a Microsoft branded login, we could do that with minimal coding effort.
The Education Sector is quite invested in Microsoft for user accounts across Australasia. Certain Australian states have a state-wide Active Directory and in New Zealand, the Ministry of Education has an agreement with Microsoft in place.
I followed the FusionAuth documented steps for Azure AD OpenID Connect and can confirm that the Single Sign On for Azure AD via the Generic OIDC connector works for both:
-
Single Tenanted Azure AD Application
- "Discover endpoints" switched on
- Issuer:
https://login.microsoftonline.com/${tenantId}/v2.0
-
Multi-Tenanted Azure AD Application
- "Discover endpoints" switched on
- Issuer:
https://login.microsoftonline.com/common/v2.0
Via the multi-tenanted endpoint URL we have made it into the final stages of the Microsoft's Azure Active Directory (AD) App Gallery App approval process. 👌
(Annnd that's enough Microsoft buzzwords for one day...)
In my readings Microsoft recommend new apps use OIDC instead of SAML so as @robotdan mentioned I'm hoping it should be relatively easy to add Microsoft as another IDP with some predefined URLs.
Caveat with this though is #222 - The current OIDC reconcile lambda is setting the User Profile picture to a generic URL (https://graph.microsoft.com/v1.0/me/photo/$value
) which returns a user's profile image based on their supplied Microsoft access token. So there may need to be some thought around creating a default Microsoft IDP lambda that can fetch and set the users profile image on reconcile for better Developer Experience (DX).
@matthewhartstonge thanks for that excellent detail!
So it sounds like you have this working - can you clarify the need for this specific IdP? Is it to support the multi-tenant Azure AD better than we do today? If so, what specifically do we need to add to make this work better for you?
Re: #222 - you can now make an HTTP request in a lambda function, so in theory this will work today?
- https://github.com/FusionAuth/fusionauth-issues/issues/222#issuecomment-1173985429
Is it to support the multi-tenant Azure AD better than we do today?
In terms of supporting multi-tenant Azure AD SSO, as far as I know through my testing, there is nothing FusionAuth needs to change for the OIDC connector to work - it's simply a matter of updating the issuer URL to the https://login.microsoftonline.com/common/v2.0
endpoint.
Just turned out the day I tested the /common
endpoint Azure AD Single Sign On was down 🙃
Can you clarify the need for this specific IdP?
The main benefit would be for FusionAuth to be able to say MS SSO is configurable 'out of the box' for enterprisey customers or those that work with B2B more than anything, for example, being able to say:
- Under IdPs, Click "Azure AD"
- Fill in your Tenant ID, Client ID and Secret
- Flip the switch if you want it multi-tenanted
- Button theming included 🎉
This definitely would've added to the sway with us jumping on board (Going in we knew we may have been able to work around it with FusionAuth's support for OIDC+SAML) - but as long as it's documented it's a win.
What specifically do we need to add to make this work better for you?
I would definitely expect for others that having a working example for getting a users profile picture via the reconcile lambda would be a bonus. As a company, we don't require this, as our system is considered the source of truth. 😄
Thanks @matthewhartstonge - really appreciate the thoughtful response. I agree, I think having a "typed" IdP for Microsoft / Azure AD would be cooler.
It seems like this "Microsoft" company is going to be around for a while 😉, so maybe it is time they get their own themed button.
"Login with Microsoft" through OpenID is vulnerable to nOAuth. A dedicated IdP integration is the proper solution.