I am working on one project with angular 7, we have already SSO but I need to use Microsoft Graphs. Right now I am trying with MSAL (#azure/msal-angular) but I can not find the way for make login with MSAL using only #username and #password.
MsalModule.forRoot({
clientID: "1231231-1212-4566-2345-fssfr34fsdf" })
Any idea.
You can't send the username/password in an API call to get an authentication token. Microsoft Graph doesn't support this.
If you are ok with authenticating without user context i.e. application only context, then the client_credential flow is probably your best bet. You authenticate with an app id and secret.
Get access without a user
Related
I am setting up a login system in auth0 for a React Typescript application. Due to how the application works I am using the PKCE flow for authentication and authorization to get access tokens and refresh tokens. So far I have implemented the flow by adding a node js express server that fetches the access token and refresh token from auth0 once we have the authroization code after logging in through the /authroize endpoint on auth0. However the problem we have now is that we cant implement our custom UI onto the login page since when we hit the /authorize endpoint we are sent to the login page hosted at auth0. We would want to set up our own login form and send over the details to auth0 in order to fetch the authorization code. Is there a way to login through our own login page instead of using the one hosted by auth0, by for example hitting the right endpoint in their api to fetch an authorization code? The only other option I have seen is by changing the HTML under branding in the application dashboard but I have also read that auth0 does not recommend doing this.
I have also previously used the auth0 js SDK and there I was able to use our own custom page for login, however that SDK uses the implicit flow which does not issue refresh tokens and cannot therefore be used. In the other SPA sdk, you cant add your own UI for login since that redirects you to auth0 as well.
Assuming that you still use the Node.js server in addition to the SPA, you can ask the user for username and password, send it the Node.js server. Using the Resource Owner Password flow, the Node.js server can then request the access, refresh and ID tokens.
Please study the security implications carefully, in particular related to this authentication flow.
By implementing custom login UIs, you lose many things: hardened security of Auth0 servers, easy configuration of authentication methods without changing the application, use of ready-made Auth0 SDKs etc. I would carefully consider if it is worth it.
I am creating a SPA using React and Express. I am trying to include authentication using MSAL.js and have looked at Microsoft's tutorials for SPA. I've been able to implement this with React using #msal-react. While this does perform authentication, it does not protect the REST API from access by unauthenticated users.
I found the Active Directory Javascript Nodejs Web API that seems to provide a means for protecting the REST API using Passport and the Bearer strategy, but the links showing how to couple this with the client-side seem to be broken.
I'm not sure how to connect the authentication that is occurring on the client side with REST API. As I understand it, the authentication token has to be passed, but I am not sure how to pass that.
The server-side sample code has:
// API endpoint exposed
app.get("/api",
passport.authenticate('oauth-bearer', {session: false}),
(req, res) => {
console.log('Validated claims: ', req.authInfo);
// Service relies on the name claim.
res.status(200).json({
'name': req.authInfo['name'],
'issued-by': req.authInfo['iss'],
'issued-for': req.authInfo['aud'],
'scope': req.authInfo['scp']
});
}
);
What I tried to do on the client side was to get the account information:
import {
useAccount,
useMsal
} from "#azure/msal-react";
...
const { accounts } = useMsal();
const account = useAccount(accounts[0] || {});
From looking at account after authenticating, I thought account.idTokenClaims might have what is necessary, but have had no luck.
I am stuck because I am not sure if I have a fundamental misunderstanding of how the Bearer strategy works, if I am using MSAL or Passport (or both) incorrectly, or if this is a configuration issue. I appreciate the help!
When calling your protected REST API, you need to present an access token obtained by the client application (on behalf of the signed-in user). So the ID token won't do here -it's only meant for your client application as a proof of successful user authentication. (ideally, your client and service apps should be separate, each represented by an Azure AD app registration).
After authentication, you need to obtain an access token, by using one of the acquireToken* methods. You pass a token request object to that method. Here you need to specify what resources and permissions you are requesting an access token for. The access token that would work with calling your REST API shouldn't/won't work with other APIs.
The tutorial article you linked points to a sample using implicit flow. I would recommend using the more secure auth code flow.
This tutorial should cover your need. Check this section in particular.
p.s. for a React client app, see this.
I'm creating a game in which I would like to use firebase authentication using cloud functions for logging in and registering users. Since my dev platform (GameMaker Studio 2) doesn't have the firebase sdk, I've resulted in attempting to use the firebase auth restAPI. To authenticate a user, I have to at one point create a custom token using the users uID and then use that to login. The problem with this is that I can't really understand the flow of the authentication. How could the client have knowledge beforehand on it's userID from parameters such as email and password?
Any help in understanding the flow I need to authenticate a user will be greatly appreciated.
If you're developing on node.JS, you should be able to use npm to install the firebase package -- that would simplify things greatly.
Otherwise, the overall flow of authentication should look as follows.
Client gives email and password
Pass email & password to Firebase Authentication using your HTTP request. You should receive an auth token, and a uID if authentication was successful. (see here)
Now you have an id token that you can set as a cookie in your client's browser. You can verify this cookie by storing it in your backend for each subsequent GET request to your Node server.
We are struggling about what OAuth flow to use with our app.
We are using Node.JS as our back-end API and Angular as our front-end.
What we want to do is, log in an user, retrieve an access token and use this access token in order to make some API requests (basic POST/GET/PUT/DELETE).
A user (still unknown at this point) lands on a login form OR a register form. He proceeds to the login or the registration.
Once logged he's on his dashboard with an access token, now every time he wants to interact with the API he must use his access token in order to interoperate with the back-end. (which is a classical behavior).
This seems easy, we wanted to use the Implicit Flow but we need a client_id in order to retrieve an access token and the user is still unknown at this point.
We then thought about using the Password Grant flow because our users will have a login/password, but OAuth specs. recommend not to use it except we have no choice.
I know this is a super basic question but what kind of OAuth flow do you recommend with this ? If we have no choice we'll just use the Password Grant but wanted to explore every single solution.
Thanks !
I'm not sure I understand what you mean by:
we wanted to use the Implicit Flow but we need a
client_id in order to retrieve an access token and the user is still
unknown at this point.
If you are using Oauth2.0s implicit flow then your angular app should be registered as a public client with the authorisation server - that process would give you a unique client_id for your angular app. Your angular app can then use the implicit grant and redirect the unknown user to the authorisation server's authorise endpoint passing along in the querystring its client_id along with its redirect_uri and various other things.
The authorise endpoint will prompt the user to register/login to the identity provider and consent to the scopes your Angular app requests.
Once the user logs in (or registers), the authorisation server should then redirect back to your Angular app's registered redirect_uri passing an access_token in the hash-segment of the returned http querystring.
Sorry, I know that I'm not answering directly to your question.
But did you consider using an authentification backend as Auth0 ?
Security is key and OAuth is a complex protocol.
Auth0 give you every thing you need to manage users, use a social identity provider, and integration with Angular.
I have to develop a SSO system and I have to do it using IdentityServer4. I have gone through the documentation and examples but I have some doubts. To be honest I don't quite get it, but I am really new in Oauth2 and OpenId Connect.
We will have a bunch of clients (web apps), each of one of those will have their own Web APi. And we have to have a centraliced Login App for all of those. I think the example with the javascript client is the closes to the thing we want to achieve. Also, a user might have permission to access one client (app), but not another, so the IdentityServer must provide information about wich clients (apps), that particularly user can access.
So, These are the things I don Understand:
1.- In the documentation I can read there are two tokens, an Identity Token and Access token. But in the examples all I see are the access tokens. It seems to me that the access token is the one with all de info needed. am I wrong?
2.- Also, I have read about de Grant Types and I'am not quite sure wich one we must use. At first I thought to use the ResourceOwner password, because it requires the client, the secret, a user and a password, wich I assumed it could be the end user. I found this example http://sunilrav.com/post/How-to-Customize-Authentication-in-Identity-Server-4 were one could customise the class that validate the user and password. I thought that this could be the way to go but the documentation statesa about this grant type "...This is so called “non-interactive” authentication and is generally not recommended.". The javascript client example uses the implicit Grat type, wich the documentation states is for browser-based applications (our client apps will all be browser based using react).
3.- can my Login app be a Javascript (react) app? The example Quickstart is made in MVC.NET. This login app connects directly to de IS4 server without asking for a access token? (In the example the app is embebed in the IS4).
4.- Can I protect with IS4 a WEB API which is developed in .net framework (4.6.2) and not in .Net Core? I havent Found Any examples.
the documentatios I followed is the offcial. The examples (quickstart) are also there. (I can't post more than two links).
thank you very much for reading and for your help.
Identity Token and Access token
Identity token is the one that contains the identity of the user, that will tell the client app that what user it is. After successful login, user will be redirected to the client app with these tokens. Response will also have claims, such as permission scopes, name , email you can add custom claims as well.
Access token is used to access your protected web api resource. You have to send the access token with each request to access the api.
Grant Types
Grant types is basically how you want your client app to interact with the auth server. https://identityserver4.readthedocs.io/en/release/topics/grant_types.html
can my Login app be a Javascript (react) app? Your client app can be a javascript app but your auth server that is the identity server which will have the login/signup pages(and other login jazz) and account controllers should be you MVC app. As, everything is already done using MVC and Entity framework, why you want to re do everything.
Can I protect with IS4 a WEB API I am not sure about this one, but I dont see why you would not be able to do it.
This is a good answer for basic IdSrv flow!
UPDATE In my understanding, the answer to which Grant Type to use it depends on your client application requirement. If you want to use a Javascript client you can use Implicit Flow, but you won't be able to use refresh tokens and your access token is not 100% secured with the browser as client can access it.
If you want to open your web api to public then you can use client credentials flow. If you want to be more secure you should use Hybrid flow or HybridClient credential flow. ( again depends on the requirements ). with this you will be able to use refresh tokens and in this way your access token would be more secure.