I'm trying to authenticate my application using Microsoft OAuth 2.0. Application registration is already done.
I'm using a web browser component to make user allow the application to access user's calendars. Then I'm tracking the redirection URLs to extract the authorization code.
But the service redirects the application to an error page.
The URLs: (My application navigates user to the first URL containing authentication info)
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?response_mode=form_post&prompt=login&client_id=c36b4fd4-8b5a-4831-b146-6e4cdac90d0e&scope=https:%2F%2Fgraph.microsoft.com%2Fcalendars.readwrite &response_type=code&redirect_uri=urn:ietf:wg:oauth:2.0:oob
about:blank
https://login.live.com/Me.srf?wa=wsignin1.0&idpflag=direct&wreply=https:%2F%2Flogin.microsoftonline.com
https://login.live.com/oauth20_authorize.srf?response_mode=form_post&prompt=login&client_id=c36b4fd4-8b5a-4831-b146-6e4cdac90d0e&scope=https:%2F%2Fgraph.microsoft.com%2Fcalendars.readwrite &response_type=code&redirect_uri=urn:ietf:wg:oauth:2.0:oob&login_hint=altostratous%40outlook.com&ui_locales=en-US&display=page&uaid=1ed5dd7edad547ea9ae42599ecf8028e&issuer=mso&msproxy=1
https://login.live.com/ppsecure/post.srf?response_mode=form_post&prompt=login&client_id=c36b4fd4-8b5a-4831-b146-6e4cdac90d0e&scope=https:%2F%2Fgraph.microsoft.com%2Fcalendars.readwrite &response_type=code&redirect_uri=urn:ietf:wg:oauth:2.0:oob&login_hint=altostratous%40outlook.com&ui_locales=en-US&display=page&issuer=mso&msproxy=1&contextid=04C5394112425BED&bk=1466075419&uaid=1ed5dd7edad547ea9ae42599ecf8028e&pid=15216
https://account.live.com/Consent/Update?ru=https://login.live.com/oauth20_authorize.srf%3flc%3d1033%26response_mode%3dform_post%26prompt%3dlogin%26client_id%3dc36b4fd4-8b5a-4831-b146-6e4cdac90d0e%26scope%3dhttps%253A%252F%252Fgraph.microsoft.com%252Fcalendars.readwrite%2520%26response_type%3dcode%26redirect_uri%3durn:ietf:wg:oauth:2.0:oob%26login_hint%3daltostratous%2540outlook.com%26ui_locales%3den-US%26display%3dpage%26issuer%3dmso%26msproxy%3d1%26uaid%3d1ed5dd7edad547ea9ae42599ecf8028e%26pid%3d15216%26mkt%3dEN-US%26scft%3dDevbhujhpkAjAfbj!ZXBlvEp*4p0KUzdBN3n1IHXrQQauBhA50taNhaXBRiw83xqwtX5hxg4gWMoeOwyjHM8Rh7ou9Ho!Zxun*eKSj3YFvrDeYTKWi5Ch!tAwgEuey7KPwCE22PPek0hBJ23YxeB!zqgG8pviIyWCDZED!86SBSE%26contextid%3d04C5394112425BED&mkt=EN-US&uiflavor=web&id=293577&client_id=000000004019AB47&rd=none&scope=calendars.readwrite&cscope=
https://c1.microsoft.com/c.gif?DI=4050&did=1&t=
https://account.live.com/Consent/Update?ru=https://login.live.com/oauth20_authorize.srf%3flc%3d1033%26response_mode%3dform_post%26prompt%3dlogin%26client_id%3dc36b4fd4-8b5a-4831-b146-6e4cdac90d0e%26scope%3dhttps%253A%252F%252Fgraph.microsoft.com%252Fcalendars.readwrite%2520%26response_type%3dcode%26redirect_uri%3durn:ietf:wg:oauth:2.0:oob%26login_hint%3daltostratous%2540outlook.com%26ui_locales%3den-US%26display%3dpage%26issuer%3dmso%26msproxy%3d1%26uaid%3d1ed5dd7edad547ea9ae42599ecf8028e%26pid%3d15216%26mkt%3dEN-US%26scft%3dDevbhujhpkAjAfbj!ZXBlvEp*4p0KUzdBN3n1IHXrQQauBhA50taNhaXBRiw83xqwtX5hxg4gWMoeOwyjHM8Rh7ou9Ho!Zxun*eKSj3YFvrDeYTKWi5Ch!tAwgEuey7KPwCE22PPek0hBJ23YxeB!zqgG8pviIyWCDZED!86SBSE%26contextid%3d04C5394112425BED&mkt=EN-US&uiflavor=web&id=293577&client_id=000000004019AB47&rd=none&scope=calendars.readwrite&cscope=
https://login.live.com/ppsecure/post.srf?lc=1033&response_mode=form_post&prompt=login&client_id=c36b4fd4-8b5a-4831-b146-6e4cdac90d0e&scope=https:%2f%2fgraph.microsoft.com%2fcalendars.readwrite+&response_type=code&redirect_uri=urn:ietf:wg:oauth:2.0:oob&login_hint=altostratous%40outlook.com&ui_locales=en-US&display=page&issuer=mso&msproxy=1&mkt=EN-US&scft=DevbhujhpkAjAfbj!ZXBlvEp*4p0KUzdBN3n1IHXrQQauBhA50taNhaXBRiw83xqwtX5hxg4gWMoeOwyjHM8Rh7ou9Ho!Zxun*eKSj3YFvrDeYTKWi5Ch!tAwgEuey7KPwCE22PPek0hBJ23YxeB!zqgG8pviIyWCDZED!86SBSE&contextid=04C5394112425BED&bk=1466075521&uaid=1ed5dd7edad547ea9ae42599ecf8028e&pid=15216&fsui=1
The pages:
First it asks user to log in:
Then asks the user to allow the application.
At last this error page is shown when user accepts.
Related
We are creating a Xamarin Forms app, only Android for now, which connects to a web API also created by us (ASP.Net Core). I have managed to get OpenId Connect authentication working by:
Using Azure as the identity provider.
Using Android custom tabs to show the Microsoft's login page.
Detect when the custom tab is redirected to our redirect URL.
Get the id token and use it as the authentication bearer token sent to our web API.
Using JwtBearer authentication in the web API.
The problem appears when the id token expires. We want to get a new one without asking the user any question.
To do that, we repeat the authentication process by adding the prompt=none, id_token_hint=THE_TOKEN and login_hint=THE_USER parameters in the authentication request, as defined in the OpenId Connect specification, and supported by Azure.
During that request, we have an issue with the redirect URL:
If the redirect URL has a custom scheme (like myapp://...) Azure responds with an interaction_required error.
If the redirect URL has an HTTPS scheme, then Azure responds successfully (including the necessary parameters to continue the process), but I am not able to detect the redirect URL in the Android custom tab. So my app gets stuck in the custom tab trying to load my invalid redirect URL.
The explanation for #2 is that HTTPS URLs are handled by the browser (Chrome in this case), so it does not trigger any action that I can detect from my app. This seems reasonable.
I also tried to detect custom tab navigation events from Xamarin, trying to detect the event "manually", but failed. Such events are never triggered.
Now, as for #1, I do not have any reasonable explanation. So my question is:
Is there any way to make Azure accept a redirect URL with a custom scheme when trying to refresh an id token by using the standard prompt=none OpenId Connect parameter?
It's so strange that this simple solution is not yet implemented or is it that I can't Google it ;p) (I'm trying from last 5 days).
My requirements:
Call from Angular App (withCredentials = true) on a URL to see if it is windows user (challenge NTLM). (I may configure this based on what URL user accessing it). If it's a valid Windows user and I find them in DB, I return the Bearer Token.
If Above call returns Unauthorised (401), I show login form to user in my AngularJS (1.6) client. User provides non-windows username and password and when user click Login, from angular service go to another URL (for getting Bearer Token - standard OWIN stuff).
** In any case above, I store Bearer Token in my client for any further API interaction.
I'm not using ASP.NET identity but I have my own DAL to verify user from DB.
I'm going to have my own custom Authorise (inherited) attribute (which will check for Bearer Token only).
I don't want users to enter Windows login on my form and to authenticate them from Active Directory.
I Don't want windows users to click on any separate button to login. (They should just login seamless - with prompt from browser asking them windows login)
I've seen hundreds of posts but nowhere I could see exactly what need. Either the mixed authentication needs to be Cookie based or separate MVC implementation. (Lot's of confusion)
Already referred:
https://techblog.dorogin.com/mixed-windows-forms-authentication-for-ajax-single-page-application-e4aaaac0424a
https://techblog.dorogin.com/mixed-windows-forms-authentication-for-ajax-single-page-application-e4aaaac0424a
https://github.com/MohammadYounes/OWIN-MixedAuth
Don't know if this may help: (but again with cookie) https://github.com/pysco68/Pysco68.Owin.Authentication.Ntlm
Can someone please help?
I may have to give up on this by tomorrow evening :-(
I am using Spring Security to authenticate with SAML and Okta, generally it works, I am able to authenticate a user and access secured URLs within my application. So far so good.
Now I have a requirement for a special type of 'internal' users to use different authentication mechanism (those users will not be in AD nor Okta) - so if authentication fails using Okta I want to display different login page. Problem is that I am unable to redirect from Okta login page to my custom page after unsuccessful login, seems like Okta will not redirect even after many unsuccessful attempts.
Is there a way to implement such requirement?
You can't redirect Okta on a failed authentication. You will need to determine what type of authentication to use prior to validating the username and password. Okta supports application based custom login page and so when the user tries to access the application, Okta redirects to your login page. From there your login page will determine where to authenticate the user.
Okta configuration for custom login page
You can use Okta's Authentication APIs and SDKs to authenticate against AD and custom code.
I'm trying to understand how to make sure that a logged on user's account is still "valid" (where valid means for example not locked out, not deleted)
I've set up an identity provider using IdentityServer v3. On the "relying party"-side, I have an ASP.NET WebApi hosted using Owin. On the RP-side, I'm using UseOpenIdConnectAuthentication to install the OpenIdConnectAuthenticationMiddleware in the Owin pipeline.
What's working so far:
Any unauthenticated user visiting my web app is redirected to the login page on IdentityServer
The user logs on (I'm using the implicit flow)
The user is redirected back to my web app
My web app receives the JWT containing the id token and access token
My web app calls the user info endpoint to retrieve the claims using the access token
My web app creates a new ClaimsIdentity containing the claims my app is interested of. This is then persisted in a cookie, using:
app.UseCookieAuthentication(new CookieAuthenticationOptions
{
AuthenticationType = "Cookies",
SlidingExpiration = true
});
This works fine, but I want some kind of hourly validation that the user is still "valid" from the identity servers perspective.
Is there some standard pattern how I should re-validate that a user account is valid? I don't want to force the user to log on again, I just want to confirm that a user can't stay on forever even if his user account is deleted.
You can send the user to the Authorization Server again with an OpenID Connect authentication request but with the additional parameter prompt=none as documented in the spec: http://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint If that returns successfully, the user is still logged in, else an error will be returned. The user will not be prompted in either case.
We are building a SPA application using Durandal and we are authenticating the users via Windows ACS in Windows Azure.
We currently have a problem with users who leaves their applications open for a long time. When they come back, the ACS token is expired and the application won't redirect to the ACS login (since it is a SPA application).
Is there a good way to detect on the client side when the Windows ACS session times out?
I don't know Durandal, but I know all Ajax calls feature (optional) error handlers in which you can test whether the server status code is 401 or 403.
(that's usually the case when the user tries to access a secure resource when he is not authenticated).
All you have to do is redirect the user to ACS with the correct parameters when this happens.