I have a angular application with URL: https://abc.xyz.com hosted within Azure App Service. This has a backend API hosted using a separate Azure App Service and different URL: https://xxx.yyy.com. Both the endpoints are registered with AzureAD. Only authenticated users can login into the application and all the requests to the API has to pass the token via the header from the frontend services layer.
Lets say there is a route within the application: https://abc.xyz.com/#!/test/100
Now when I open a new browser instance and try the above URL, it asks me to follow all the steps required for AzureAD authentication and navigates me to the landing page:https://xyz.abc.com instead of https://abc.xyz.com/#!/test/100
In this case I am expecting user to be navigated to the requested route : https://abc.xyz.com/#!/test/100 instead of taking him to the landing page: https://abc.xyz.com/ post authentication process.
Can anyone provide their guidance regarding this scenario?
Please check if below points give some idea.
AFAIK, the default behavior is to redirect the user to the original
page i.e; the redirect url mentioned in the app registration process,
as microsoft identity basically checks the state whether is protected
by Azure AD before the location is changed to other path than that.
Please check this blog on Redirect to a custom login page when
securing your Angular app with MSAL - Waldek Mastykarz to try the
page redirect to the path previews required.
You may also try adding another redirect url of that path in azure
ad portal.
Related
If I use the Hosted UI in App Client on Cognito, the redirect works perfectly. However, if I create my own login pages, it doesn't redirect to the site I want.
This is in a Single Page Application using VueJS and I have also tried with React. The sign in page works, and it signs the user in, however, I expect that it will automatically redirect to the redirect path I have set in the Cognito as that is what happens when using the Hosted UI in Cognito. However, it doesn't redirect to that site and I am unable to login to the redirect site.
It appears that the Hosted UI handles all of the authorization and is able to pass the needed credentials to where it can login to the redirect site.
Perhaps I am just using this wrong? I need to have custom sign in and sign up forms, so I can't use the Hosted UI. But I need the Sign In to redirect to the external website and handle all of the login credentials where the user will be authorized and logged in. Hopefully I explained that ok...
Any help would be greatly appreciated. Again, I am well versed in how this all works... Thanks.
Once you use Hosted UI in Cognito, provides you an OAuth 2.0 compliant authorization server. If you don't use the hosted UI , you have to build this capability your self for the Oauth flows (ex - implicit, Authorization code etc) along with the callback/redirect functionality.
Just to note the hosted UI can have a custom domain and the styling can also be adjusted, please check here.
I have a website protected by azure ad and uses msal, i want to access it in iframe, but it looks it does not work. Is there a way to make it work ? Is it related to the redirect url or other issue ?
You cannot authenticate the user inside iframe meaning you cannot use redirect APIs for user interaction with the identity provider.
You can start with creating your own customer page and allow the user to enter the credentials and then authenticate the user. When the user enters their credentials and clicks on login, the server will return OK (if email/password is correct). After that you should save the token in localstorage and then set isAuthenticated = true.
If you are using the Auth code flow, then you should do the authentication in the outer real page not inside the iframe. Then you will have to login once your authenticated. The concept is that you must fully redirect to the Auth pages in azure ad not in iframe.
You can achieve single sign-on between iframed and parent apps with
the same-origin and with cross-origin if you pass an account hint from
the parent app to the iframed app.
Learn more here
You need to specify in the auth config to allow redirects in IFrame
https://azuread.github.io/microsoft-authentication-library-for-js/ref/modules/_azure_msal_browser.html
We want develop few different services (React Apps) with the same users database and Rest API.
Some users might have access to APP 1, some for APP 2, some for both depends on their role.
We decided to go on multiple subdomain apps method.
We want SSO so only one page/app to authenticate all the apps and not a local login component for each app. using JWT mechanism in our backend.
STRUCTURE:
AUTH FLOW:
There are two main problems in this flow which are marked as 1 and 2:
Lets say i go to the login app and log in, getting accestoken from the backend.
How do i deliver the token to app1.company.com? should react login APP redirect with token in url param?
local storage is subdomain scoped.
iframe has problems with Safari.
I don't wanna save jwt in cookies for now because the flask REST can serve non-browser retailed clients.
Lets say the user want to go to app2. if we aren't able to share the token from app1 with iframes or any other method, then this app should be redirected to login and make the process again as app1, which is fine for us.
But is this really the way? if token is invalid anymore and we get Error from backend, should we redirect to the login app in the other subdomain (embed the url we wanna go back to after login success)?
Can i just use 3rd party Open id connect service?
Should i consider microfrontends approcah to make the all the "apps" on the same domain?
How "Attlassian" as an example handles this process?
What am i missing and what is the best way to solve this flow?
Lets say i go to the login app and log in, getting accestoken from the backend. How do i deliver the token to app1.company.com?
It is not a problem that login.company.com delivers the token as a parameter in the URL, because the site can verify the authenticity of the token by verifying the digital signature or with a specific endpoint in the central authentication domain. This is how openid/oauth2 does it using the "implicit" flow, although they also allows to send the token as POST, or use a 2-step flow ("authorization_code" flow)
Lets say the user want to go to app2. if we aren't able to share the token from app1 with iframes or any other method, then this app should be redirected to login and make the process again as app1, which is fine for us. But is this really the way?
You can share the token between domains using an internal iframe, but in your case I would recommend that each domain use its own token.
if token is invalid anymore and we get Error from backend, should we redirect to the login app in the other subdomain (embed the url we wanna go back to after login success)?
Yes, in the number 2) of your drawing, just redirect from app2.company.com to login.company.com and follow the same flow as in 1). You will need some type of cookie on login.company.com to avoid requesting credentials from the user again
Can i just use 3rd party Open id connect service?
Yes, you can use an external OpenIdConnect service, or deploy at login.company.com an OpenIdConnect server like IdentityServer or KeyCloak
Should i consider microfrontends approcah to make the all the "apps" on the same domain?
It is not necessary having a central authentication domain
How "Attlassian" as an example handles this process?
I don't know exactly how Attlassian does it, but currently most web services support OpenIdConnect
I'm getting started with Identity Server 4 (under ASP.NET Core) using the Implicit flow to secure an Angular 2 front end (to Web API services).
Using the oidc-client JS library, I can successfully redirect from the sample's default page to my login page, have the user authenticate, then redirect (via /connect/authorize) back the the Angular site's callback.
If a user browses directly to my authentication login page (rather than the Angular home page), I can then authenticate, but have nowhere to redirect to. If I redirect manually to the auth server's /connect/authorize page, the OIDC Client reports "No matching state found in storage". (Presumably, the OIDC Client is persisting something locally to verify the response against the original request?).
An obvious solution is for the Auth server to redirect any requests without a redirect specified to the Angular client, which could then redirect back to the Auth server as normal. That feels like a lot of round trips though.
Yes - because this is not how it works. The authentication flow starts at the client application - not the identity provider.
An OpenID Connect provider typically has more then one client - so it needs contextual information (aka a valid OIDC authorize request).
If you want that the journey starts at the provider you need to do something like you proposed - but once you have a 2nd client you need to be smarter about that (e.g. a selection screen etc).
I would like to add an authentication mechanism to my AngularJS app with Firebase backend. The requirements are simple:
Authenticated users should be able to access any page.
If unauthenticated users goes to /some_page (any page except /login), they should be redirected to /login. Once they enter the right credentials, they should be redirected to back to /other_page.
Possible solution that is described here makes the following assumption:
My solution assumes the following server side behaviour: for every
/resources/* call, if user is not authorized, response a 401 status
But, I'm not sure if it is possible to enforce this behavior when using Firebase as a backend.
Any help and/or examples to implement such AngularJS+Firebase integration will be appreciated!
One solution is to do your routing on the client side with the $route service.
When a user authenticates through Firebase, save some record of this on the client, like in localstorage, some all-encompassing controller, or your own Angular service (my preferred option).
In your routing controller, if the user is authenticated, redirect to /some_page, otherwise redirect to /login and keep track of the $location where the user intended to go.
If, on the other hand, you want to route with your server, you could use the solution you linked to by having your server generate Firebase auth tokens.
I had the same requirement recently and came across this blog post.
http://www.42id.com/articles/firebase-authentication-and-angular-js/
It explains setting up an Angular JS application that interacts with Firebase. Also included are ways to authenticate against OAuth providers such as Google+ and Github using Firebase API, routing based on authentication status, storing user profile information on Firebase and setting up security rules on Firebase to protect user data.
If you are using Firebase Simple Login (rather than generating the authentication tokens on your own servers), you can see how to detect your login state client-side here:
Displaying text after login