The example can be found here:
https://github.com/vitNickW/TeamsAppMultiAuth/tree/main/src/TestTeamsAuthSSO
msTeamsSilent is being used to launch a popup to allow Microsoft Identity authentication to function within an IFrame (the default redirect will not work). However, the code doesn't seem to do anything with the actual JWT that is returned and it is not updating the ClaimsIdentity.
How do you:
...update the ClaimsIdentity so that an MVC project will recognize that the authentication was completed?
...get the [Authorize] tag to call the popup routine instead of doing the redirect if the user is not already authenticated?
...get the authorization to persist from one page to another?
We are OK if you only can provide a fix using .NET Code instead of .NET Framework.
We are OK if a different authenticating method is used (e.g., MSAL instead of ADAL). The important part is that we need a Popup instead of a Redirect authentication and have it recognized correctly by the MVC application.
Related
I have the following setup:
1) WebAPI that accepts JWT Bearer tokens for auth.
2) Portal (WebApp) that puts a nice face on the json output from this WebAPI. It does OpenIdConnect authentication and uses Cookies to persist login information. It is an ASP.NET Core MVC app.
3) The WebAPI and WebApp are on different domains.
4) The WebAPI layer is designed to be called by any 3rd party who can present a valid token - either via App auth (client_credential flow, for eg) OR Delegated User auth (implicit flow, for eg). The WebAPI also does RBAC auth.
At this point, the problem I have is this:
1) I want to be able to make AJAX calls from the WebApp controller pages (cshtml) to my WebAPI so that the pages are responsive and there are no POSTs. So I integrated ADAL.JS into the page for that purpose. It works from a functionality pov.
2) HOWEVER, this results in multiple authentication dialogs (web page popups).
-- 1st auth popup. Upon navigation to the Portal homepage, I get challenged and have to enter my credentials on my company login page (federated AD auth).
-- 2nd auth popup. Then when I invoke anything on the Portal pages that involves ADAL.JS (namely the AJAX calls), it causes another login dialog because ADAL.JS cannot see the login cookie from ADAL.NET layer. This dialog comes up and goes away without any input needed tho (because the cookies from (1) are sent along to the server automatically by the browser). At this point, I have the ID_TOKEN and an ACCESSTOKEN for the PortalApp's client_id show up in the ADAL localStorage area.
-- 3rd auth popup. Then another dialog pops up; it uses a Hello pin login (I assume this is due to 2-factor auth requirement enforced by my tenant). At this point, I see the ACCESS TOKEN for the WebAPIApp's client_id show up in the ADAL LocalStorage area.
And now my AJAX calls start working.
Is there a better way to do this so that I can get the benefits of AJAX and not have to resort to serverside POSTs and have only 1 auth dialog instead of 3?
(I thought of may be switching ALL authentication to be done by ADAL.JS for the entire site, but I like the paradigm of using the [Authorize] flags and RBAC for the Controllers. OR is there a way to make my WebAPI accept both JWT and Cookie authentication?
Thanks!
I am trying to add ‘keep me logged in’ functionality to my auth0 v9.3.0 authentication flow in my SPA. I have an embedded page at app.domain.io/login where the user enters their credentials. When they hit the sign-in button, the app calls the login() method from auth.js, passing in the username and password. If they checked the box, a permission cookie is set to true.
When the user launches the page later, after the token expires, a router guard calls auth0.js’s checkSession() method to get a new token. At this point, checkSession returns a login_required error even after the user logged in with auth0.js’s login() method. If I instead call the authorize() method and have the user log in on the hosted page, checkSession succeeds and does not return a login_required error.
Why does calling the login() method from the embedded page not fulfill the login_required requirement that authorize() fulfills? I want to get this working without ever redirecting the user to the hosted auth0 page.
Update: 03/28/18
I am currently using auth0 v9.3.0.
Instead of calling the login() method, I am now using axios to make a request to the co/authenticate endpoint. This succeeds and returns a login_ticket, co_id, and co_verifier.
When I call authorize() from auth0.js and pass in the login_ticket as mentioned in the documentation (https://raw.githubusercontent.com/jaredhanson/draft-openid-connect-cross-origin-authentication/master/Draft-1.0.txt), I get a ‘No verifier returned from client’ error. I have the co_verifier, but I’m not sure what to do with it.
Here is a fully working sample to follow (SPA using plain JavaScript). The sample illustrates both embedded login and universal login (auth0 hosted login page) approaches.
If you have a codebase on Github and don't mind sharing, then I can take a look for you. Please also update your question to indicate version of auth0.js you are using (or put in comment section below). Do you know (you can check using web browser developer tools) whether you are using co/authenticate endpoint when authenticating using auth0.js embedded login? If so, then you would have a Single Sign On session. However, if you are using oauth/token endpoint then this would not create a single sign on session. the checkSession() function calls authorize?prompt=none under the covers, which detects whether a SSO session is present as part of the authentication process.
Finally, and just for the record, the strong recommendation is to use Auth0 Hosted Login Page (Universal Login). It is a superior approach from security standpoint, and offers other benefits like easy opt-in to services like MFA out of the box. Finally, you could also enable Custom Domains so that your website and the Auth0 Hosted Login Page share the same URL base origin (domain) - end users of your site would not recognise they have been redirected to Auth0 for the authentication. So it is pretty seamless from a UX perspective too.
This issue was solved by calling auth.crossOriginAuthentication.login() instead of auth.client.login(). auth.crossOriginAuthentication.login() goes through co/authenticate, auth.client.login() goes through oauth/token.
Trying to search for this results many many results for securing a WebAPI and how to secure an MVC application, but i could not find a solution.
What i want to achieve:
i have an MVC website with a modal Login form,
When the user enters he's credentials to the the form, an Ajax request is sent to a WebAPI with the credentials.
The WebAPI should return (i guess a ticket, since that is what i found).
The ticket would be then saved into the sessionStorage of the browser (no cookies),
Each page request to the website will check for the token, and enable/disable the parts that need to be secured.
All the examples i have found are showing either MVC only authentication,
or WebAPI authentication, but i could not find anything that does the described above.
The sessionStorage is available only for client-side use. You can manipulate or retrieve values from the storage using Javascript, but you can't directly read data from the server. Since MVC typically renders HTML Views server side, you have no options to send the token stored in the sessionStorage on each request.
The situation you described is an hybrid solution which can't be achieved without the use of cookies.
A simple solution is to set the login data (specifically the token if you will use a token-based approach) in a cookie issued by the Web API endpoint during the login phase.
I have been playing with Thinktecture IdentityServer3 and am keen to use it as the product looks great. However, I don't fully understand how to accomplish my flow which is probably fairly common:
Create Identity Server using Implicit flow
Setup an MVC web site
Setup a separate Web API
So far so good, as demonstrated in the examples on the site. I now wish to call the API using AJAX calls directly but for this i need an access token. It seems like a large overhead to have to route these through the MVC site itself (again, in the examples).
How can I accomplish this flow? Would it essentially blend the MVC and Javascript Client samples or is there a smoother way so the user only has to sign in once? Perhaps send the access token in a hidden field but then how would it renew?
Any help on understanding this would be great.
I've managed to come up with a solution which seems to work, not sure if it's best practice though...
Expose a method on the MVC site at AJAX/AccessToken
Method should be locked down with Authorize attribute to ensure the MVC part of the site is authenticating properly with IdentityServer
Method returns the users Access Token which was generated through the above call via MVC controllers
In JavaScript, simply use this endpoint to get an Access Token and then call the API manually
The call to get the Access Token should be secure as its within the same domain/authentication model as the MVC site itself
I've put up a sample here for anyone interested:
OIDC-Website
Check out the form post client to see the endpoints being called explicitly. You will need to hit the token endpoint to get your access token.
You should be able to use these endpoints in your AJAX calls, store the received claims and tokens in a cookie and take it from there.
Note that to renew the access token, you will also need to store the refresh token. The Implicit flow does not allow for refresh tokens (you'll need to use the Authorization Code Flow or the Hybrid Flow).
I have implemented an OAuth2 authentication mechanism in my GWT app. The OAuth2 server is based on Spring framework 3.x (using its Spring security OAuth2 implementation).
I am using the OAuth2 "Authorization code flow" to get the user authenticated (though implicit flow may have been a better choice in our case). So at first, the user is redirected to the OAuth2 server authentication page, he enters his credentials and if he is successfully authenticated, he is redirected back to a url with an oauth code. He will then make a second call to get an access token from the OAuth2 server.
Now, the issue is, we would like the user to be able to bookmark a page in the application and directly access it. If he has already authenticated then he would have direct access to it (no more auth involved). Otherwise, he would have to go into the OAuth2 authentication flow but in the end, should be redirected back to the bookmarked page he intended to access at the beginning.
How can I store this page url and get redirected to it after the user successfully authenticates ?
any help would be appreciated. Thanks!
EDITED
The initial url redirection is done via javascript's document.location.href
The way to maintain the original URI in an OAuth 2.0 Authorization Grant flow is to pass it in the state parameter so that the redirection endpoint can use it, after it exchange the authorization code for an access token, to redirect the user back to that URI.
FYI, this is exactly what Google suggests in the examples in their OAuth 2.0 documentation, e.g. https://developers.google.com/accounts/docs/OAuth2Login
Original answer:
The problem is using the hash part of the URL for the place, which is not sent to the server and thus cannot be used in the redirection to the OAuth2 server authentication page.
You have 2 (maybe 3) solutions:
stop using the hash for the place and switch to HTML5 History; either through gwt-pushstate at the History level, or a custom PlaceHistoryHandler.Historian if you use the Places API. That limits your audience though: http://caniuse.com/history
stop using an HTTP redirect, and instead use JavaScript so you can put the hash in the OAuth2 redirect_uri. So instead of redirecting, send an error page with the appropriate scripts bits.
some browsers append the hash to the URL after a redirection, so your OAuth2 server might be able to pick it (in JavaScript) and append it to the redirect_uri. That might depend on the HTTP status code used for redirecting (from experience, it works with a 301, but you don't want a 301 here). Needs testing.
You can do this using GWT activities and places.