We have a news application where the reply url is not fixed. And it could be anything in our system. Azure AD B2C currently supports only 20 reply urls in app so we cant add more reply urls as well.
So we either need
1. Wild card reply urls OR
2. some way to have as many reply urls as we want.
Wild card reply urls have a potential threat
The threat related to this is called “Open Redirector” and is discussed in sections 4.1.5 (Threat: Open Redirectors on Client) and 4.2.4 (Threat: Open Redirector) of RFC 6819 (OAuth 2.0 Threat Model and Security Considerations). The mitigation is specified in section 5.2.3.5 (Validate Pre-Registered “redirect_uri”).
When the number of reply URLs is large and based on some input parameters, it is advisable to consider the following practice:
Create a ‘common’ reply URL per application, and register it in AAD B2C. All replies from AAD B2C will go to this reply URL.
The application can store branding related information on the local client (e.g. session cookie, HTML5 local storage).
After an authorization request, Azure AD B2C will send the response back on the ‘common’ reply URL.
At this point, the application can read the local storage and redirect to the correct URL based on the parameters stored locally.
This approach is also more scalable because every reply URL does not need to be registered with the application. Likewise when some branding is removed from the aplication, there is no management task to remember to delete that reply URL from the application.
With some applications (e.g. news websites) this is the only practical approach to avoid maintaining thousands (if not) of reply URLs in the directory.
Related
We need help in implementation of MS Login and SSO together on same azure application and we are facing below challenges.
Currently we have implemented MSLogin and SSO authentication with independent Azure application and it is working as expected.
But now customer is expecting that instead of configuring the MSLogin and SSO authentication setting independently in azure for two application can we have it with one azure application only.
Based on above scenario I have following question:
Can we implement MSLogin and SSO authentication together? If any lead would be highly appreciated.
Currently I have some partial implementation of the above approach but facing challenge with redirect URL.
Issue: If I configure the same application for MSLogin & SSO authentication then
For MSLogin its mandatory for us to provide the redirect URL and if we don’t pass it then MSLogin authentication not working.
If we pass this redirect url then the reply URL which we have set for SSO is not getting triggered and always redirecting to MSLogin redirect URL only through azure cloud (don’t have any control).
Any help on above issue is highly appreciated.
• The redirect URL option is featured with those apps who have custom app registrations other than that of Azure apps specified in the gallery for whom the redirect URL is already configured inbuilt to be of Azure sign out page.
• That’s why, the sign out URL is of utmost importance in enterprise applications from where the Identity signing out of that platform is confirmed. Thus, you can check the following method of using a state parameter while configuring the redirect URLs might be useful.
• Create a "shared" redirect URI per application to process the security tokens you receive from the authorization endpoint.
• Your application can send application-specific parameters (such as subdomain URL where the user originated or anything like branding information) in the state parameter. When using a state parameter, guard against CSRF protection as specified in section 10.12 of RFC 6749).
• The application-specific parameters will include all the information needed for the application to render the correct experience for the user, that is, construct the appropriate application state. The Azure AD authorization endpoint strips HTML from the state parameter so make sure you are not passing HTML content in this parameter.
• When Azure AD sends a response to the "shared" redirect URI, it will send the state parameter back to the application.
• The application can then use the value in the state parameter to determine which URL to further send the user to. Make sure you validate for CSRF protection.
• Also, the client must protect these parameters by encrypting the state or verifying it by some means as you are using a personal Microsoft login for authentication purposes which means personal Microsoft accounts will be able to access the application configured in Azure AD, so please validate the domain name in the redirect URI against the token.
Please find the below links for more information: -
https://learn.microsoft.com/en-us/azure/active-directory/develop/reply-url
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-microsoft
I have multiple sub-domains listed in a SaaS app. The app provides options to configure SSO with Onelogin, however it provides the option to Enter only one SAML Endpoint(to which users will be redirected) and One certificate.
In this specific case with Onelogin, the certificate with One login is same across different apps that are setup at Onelogin, however each app has a different SAML endpoint. This makes it impossible to configure SSO with multiple sub-domains of the SAML app.
Tried using SAML Connectors (Advanced) in Onelogin, however when multiple connectors are setup each still has a different SAML endpoint.
Any help in configuring an app in Onelogin using same SAML Endpoint would be very helpful.
You're at the mercy of your SP here. If it only supports one IdP, then there's nothing you can put in place in Onelogin to mitigate that. To extend #todaynowork's answer above, the RelayState parameter might be of use to you but your SP will need to support it. The RelayState parameter allows the SAML request to include the resource your user was initially requesting. When the SAML response is verified at the ACS URL, you can then use the RelayState parameter to redirect the user to their requested resource across any of the subdomains. Assuming your SP side sessions are consistent across all subdomains, that could work for you.
Suggest you use the SP initial SSO. That support deep link. Deep link means you could pass the return url while you do auth request. After success login, it will return to 'return url' you passed.
Might seem a silly question, but Microsoft's documentation isn't very beginner friendly, I think. It uses as examples "http://localhost:31544" for the sign-on url and "http://MyFirstAADApp" for the redirect URI, but although I understand what a local host is I can't figure out what exactly the numbers on it are and how I define them for my application, and absolutely zero clue of what the redirect URI is supposed to do for a native application and how should I define a URI for my own.
To be more clear on what kind of app I'm trying to add, I merely want to acess the Office 365 management API tools and get some data from it, so I imagine a native app would fulfill my needs for now. Registering the app on Azure AD is required to do so according to Microsoft's documentation.
So expanding on the title, how to define an URI for my native app is what I would mainly like to know. Some further clarification on what exactly is the purpose of this URI as well as to how to use and/or define a localhost URL for an Web app would also be much appreciated.
I know this is ancient, but I don't see a satisfying answer here, and maybe someone will come across this and find it useful. To answer the question asked, unless you're going to work outside of the default MSAL handling of the server responses, and I don't expect you would from your description, I'd just go ahead and use the default:
https://login.microsoftonline.com/common/oauth2/nativeclient
When you go into the Azure AD portal, go to your application and, from the Overview, select the "Set RedirectURL" option, you'll add a platform and select the "Mobile and Desktop Applications" and you'll be provided with the choice of 3 URLs to choose from. My understanding is this is just there for custom handling of authorization tokens and is telling MS where to send those tokens. The MSAL library functions seem to use this link as well, so they're probably handling this in the backend.
I agree with the OP though, the MS docs are severely lacking for newcomers and I wasn't able to find an end-to-end description of what needs to happen to get, in my case, a desktop application to send email through Office365 using 2FA. I would forge ahead as best I could until I hit the next error, then explore that, sort it, then slam into the next one. Rinse and repeat. This was made extra tedious as I had to go through a 3rd party IT group to get the 2FA access codes every time I wanted to test.
Best of luck, hope this helps someone!
how to define an URI for my native app is what I would mainly like to
know.
You should provide a Redirect URI that is unique to your application as it will return to this URI when authentication is complete.
In your application, you will need to add a class level variables that are required for the authentication flow, include ClientId and Redirect URI.
Here is the diagram:
Native application makes a request to the authorization endpoint in Azure AD, this request includes the Application IP ,Redirect URI and application ID URI for the web api.
After user signed in, Azure AD issues an authorization code response back to the client application's redirect URI. After that, the client application stops browser interaction and extracts the authorization code from the response.
Then the client app use this code to sends a request to Azure AD's token endpoint. upon successful validation, Azure AD returns two tokens.
Over HTTPS, the client app uses the returned JWT access token to add the JWT string with a “Bearer” designation in the Authorization header of the request to the web API. The web API then validates the JWT token, and if validation is successful, returns the desired resource.
More information about it, please refer to this article.
For native you can set redirect to be equal to the Application ID URI, which now defaults to look like //app:{ApplicationId}
Redirect uri be starts with SSL URL, so select your project, enable SSL URL and use this auto generated SSL URL (for example : https://localhost:port#) as redirect uri , same to be updated in the azure app registration as additional redirect URIs
I am creating a website that contains a bracket system for a Rocket League tournament. I have set up OpenID for Steam, so that handles PC users. However I am trying to branch out to the console communities. Is there a way I can use OpenID to allow a user to sign into my website with their PSN login?
I mainly just need their ID to keep track of their scores, but if I can get a
PSN API to work with an OpenID login it would be fantastic!
Thanks in advance?
See:
http://www.programmableweb.com/api/psn-sign
This may be what you need:
This API allows people to use the Playstation Network SignIn for their
own sites. If a developer's site URL is allowed by Sony, they can set
their site as the returnURL by GET. This allows them to bypass Sony's
official External PSN Sign In page. The site forwards to a developer's
site on a successful sign in with a sessionId by GET. There is no
official public API to convert the sessionId into a user specific
value (like the PSN-ID). The API converts a valid sessionID into a
proper PSN-ID.
You didn't say what did you try so far so I don't know it you already tried that or not.
We have one web application (sharepoint) that collects information from disparate sources. We would like to be able to link users to the main websites of those various sources and have them pre-authenticated. I.E. they enter their credentials for the other sources (which are a number of different types LDAP, AD and home grown!) and we retrieve some information for them, and remember there details (Possibly Single Sign-on to keep em nice and safe). The user can then click a link that will open the full app in another window already authenticated.
Is this even likely to be possible?
Office Server has a Single-Sign-On api as a builtin feature. you may want to look into that. It enables you to register user credentials securely, and to access it at runtime.
You need to act as a web browser acts to different sites with storing credentials (usually in cookies) locally. Use therefore a a proper client library with cookie support. This could go probably for most of sites. There are sites using HTTP authentication, which are also easier to access from appropriate client libraries. The most demanding can be access to SSL websites, but again, most client HTTP libraries cover that nowadays as well.
All you need now is just to prepare your web application to act as a proxy to all those separate web resources. How exactly this is done in Sharepoint, well, I hope others will answer that...
True Single Sign-on is a big task. Wikipedia describes common methods and links to a few SSO projects.
If you want something lighter, I've used this approach in the past:
Create a table to store temporary security tokens somewhere that all apps can access.
From the source app (Sharepoint in your case), on request of an external app, save a security token (maybe a guid, tight expiration, and userid) in the token table.
Redirect to a request broker page/handler in the destination app. Include the final page requested and the guid in the request.
In the broker, look up the security token. If it exists and hasn't expired, authenticate, authorize, and redirect to the final page if everything is good. If not, send a permissions err.
Security-wise, a guid should be near impossible to guess. You can shrink risk by letting the tokens expire very quickly - it shouldn't take more than a few seconds to call the broker.
If the destination app uses Windows Auth and doesn't have role-based logic, you shouldn't have to do much. Just redirect and let your File/UrlAuthorization handle it. You can handle role-based permissions with the security token db if required.