I am building an application consisting of the following
SPA (Provides a front end for the user to perform actions) - app.myservice.com - React JS
API (Provides the core business logic and is called by the SPA) - api.myservice.com - Node JS
What I would like to do is allow people to "Signup" to my application (as a whole) using Office 365.
However.... I want the API to generate JWT tokens which the SPA will use to communicate with the API in the future. I do not want the SPA to have Office365 specific tokens.
The process would look like this at a high level:
User goes to app.myservice.com
User clicks "Signup"
User is redirected to Office365 to provide login details
Office365 redirects to my API
API creates a local user in its database
API generates a JWT
API returns JWT to SPA
SPA calls API using JWT to perform actions.
What is unclear to me, is what OAuth2/OpenID flow type to use in order to achieve this.
Further this, I would like to understand if my approach has any flaws in general.
Many Thanks
In step 3 above, I think your SPA should redirect to Azure AD, which is where the user signs in. Your SPA will then receive an Azure AD token and can send it to the API. The API can potentially read user info and create a user if required. APIs should not issue their own tokens or receive redirects. Not sure if this will 100% meet your requirements but it is the standard pattern for the 3 legged SPA and API OAuth 2.0 based dance.
Related
I'm struggling theese days on the possible way to configure an Authentication + authorization system to consume a REST API from a mobile application.
Scenario:
We've developed 3 independent portals for a big customer that serves several users.
To enable a SSO for the 3 portals we've implemented a SAML authentication system using SimpleSAMLphp.
Every portal has a service provider and they make assertion requests against a central IdP.
The IdP checks username and password against a database where passwords are hashed and stored during registration.
After the login, the authorization on the portals is handled by the session on the server, and so far everything was fine.
Now the customer asked us to develop a mobile application that will require the users to login and access several of their protected resources collected during the usage of the 3 portals.
We've decided to develop a frontend application using ionic that will consume a REST API made in node.js that will serve all the data (both protected and unprotected resources).
Now here comes the question: to authorize access to protected resources on the Api we'd like to use JWT to easily achieve a stateless system.
The doubt is how to perform the authentication? We've the opportunity to check the credentials directly against the database skipping the SAML process, otherwise we've to implement a solution where the SSO IdP acts as authentication provider and then when an attempt is successful the API app will get the response from the idp and then issue a signed jwt to the consumer client. Is this second way a common implementation? Is it possible?
What path do you suggest to follow? The first could be very easy to achieve, but since we're using html+js for the app's frontend, if we decide to use the second solution probably in the near future we could recycle some code from the app to modernize some functions on the web portals, maintaining the jwt pattern and consuming the new Api also on the web.
I believe that in this case will be easier to ask a token to the new api using someway the logged in user's data already in the session of the portal. Sounds possible?
I hope that everything was clear, any help will be appreciated!
Thanks
The key goal here is to code your apps in the best way, via
the latest security standards (OAuth 2.0 and Open Id Connect).
SAML is an outdated protocol that is not web / mobile / API friendly, and does not fit with modern coding models.
Sounds like you want to do OAuth but you do not have an OAuth Authorization Server, which is a key part of the solution. If you could migrate to one you would have the best future options for your apps.
OPTION 1
Use the most standard and simple option - but users have to login with a new login screen + credentials:
Mobile or Web UI uses Authorization Flow (PKCE) and redirects to an Authorization Server to sign the user in
Mobile or Web UI receives an access token after login that can be sent to the API
Access token format is most commonly a JWT that the API can validate and identify the user from
The API is not involved in the login or token issuing processes
OPTION 2
Extend option 1 to federate to your SAML Identity Provider - enables users to login in the existing way:
The Authorization Server is configured to trust your SAML based identity provider and to redirect to it during logins
The SAML idp presents a login screen and then posts a SAML token to the Authorization Server
The Authorization Server issues OAuth based tokens based on the SAML token details
OPTION 3
Use a bridging solution (not really recommended but sometimes worth considering if you have no proper authorization server - at least it gets your apps using OAuth tokens):
Mobile or Web UI uses Resource Owner Password Grant and sends credentials to a new OAuth endpoint that you develop
OAuth endpoint provides a /oauth/token endpoint to receive the request
OAuth endpoint checks the credentials against the database - or translates to a SAML request that is forwarded to the IDP
OAuth endpoint does its own issuing of JWT access tokens via a third party library (if credentials are valid)
Web or Mobile UI sends JWT access token to API
API validates received JWT access token
I'm having difficulties finding documentation for auth0 and microsoft graph integration. My end goal is to have a SPA that can login with a microsoft profile to auth0 (connected to azure ad). Then I want my app to get a token for microsoft graph and do some api calls.
As I've understood it so far, auth0 does not allow you to get the access token to different identity providers in a front end application, but rather that they should use a proxy to get this token. My flow therefore is:
I login with a SPA auth0 app (using a microsoft identity)
This is then used to authenticate to a backend server using a api registration in auth0
The backend has its seperate machine-to-machine app in auth0
Backend api uses this seperate app to get access token to auth0 management api
Current user is fetched (based on the logged in user from front end app login) from management api,
Here i find an access token under the azure identity (if I do the same in the front end, the access tokens are omitted)
Token does not work to call graph, I am unsure of where to send it next.
I am aware that the above is probably completely wrong, that's why I am here :)
My questions are:
1) Is it even possible to get an access token for microsoft graph starting from a login to auth0 in the way I want it to. If not, can it be done from a backend?
2) Does anyone have a link that discusses this, ideally with some code samples.
To answer your first question:
1) Is it even possible to get an access token for microsoft graph starting from a login to auth0 in the way I want it to. If not, can it be done from a backend?
I have had the chance to authenticate apps using the microsoft identity library called MSAl whose documentation is found here. It gives a pretty detailed way to authenticate directly from your SPA.
I have also used the microsoft javascript sdk as it comes inbuilt with token caching and refreshing so that I do not need to build that for myself.
In relation to this,
Does anyone have a link that discusses this, ideally with some code samples.
You can find the samples well described in the samples section of the SDK
I hope this helps.
Is it recommended or good practice to protect a Web API directly with Open ID Connect or not?
The setup:
Mobile App
Authorization Server (ADFS 4.0)
Web API (ASP.NET Core)
Currently I do the normal OAuth2 "Authorization Code Flow", and then pass the access_code to my Web API in the HTTP Header as "Authorization: Bearer ".
In ASP.NET core I just do the usual
services.AddAuthentication(...).AddJwtBearer(...)
Works fine.
But everyone talks about OAuth2 beeing only "pseudo-authentication" with certain flaws. I want my Users to be a properly authenticated before using my Web API. So it seems like Open ID Connect should be the way to go, aka "real authentication".
But does it actually work to "consume" Open ID Connect authentication in an ASP.NET Core Web API? And if yes, how? And is it good practice? All samples seem to be about Web Sites, not Web APIs.
There is an extension method
services.AddAuthentication(...).AddOpenIdConnect()
But here Implement OpenID connect Authetication in asp.net WEB API they state that "this component is designed for user interactive clients".
What i also don't understand, what would I do with the "id_token" I get from Open ID connect.
Currently i just pass the "access_token" as Bearer.
How do i consume the id_token?
Some clarifications:
The API does not act on behalf of a user (access to company data).
The API already has access to the "data". It does not require any auth workflows for itself nor does it need to pass the users credentials along.
The API needs to know "WHO" the user is, and it has to be done in an modern and good way
That's why I was thinking of OICD with its "real auth" (VS Oauth2-only which is "pseudo").
I basically cannot wrap my head around how the stuff returned from OICD (id_token) will be passed to my Web API.
OIDC is an OAuth workflow. It merely extends OAuth; it is not a replacement for it. APIs are typically authorized either by token or client secret. The difference is simply whether it's acting on behalf of a specific user or not. For example, something like the Facebook API has both workflows for its API, you generally operate with Facebook's API as a client app using the app id and client secret for your app, or you can do user-specific things like create a post on the user's wall given an authorization token.
That authorization token almost invariably comes from an OAuth workflow. Given your stated setup, your mobile app would handle this to get an auth token for the user from your ADFS server. Your API, meanwhile, would actually probably do both. It would communicate both using an assigned client secret and a user auth token, if the mobile app provides it with one.
I have developer an API that is secured by oAuth2 and Azure B2C. I now want to access that API from a legacy web forms application which is using Forms as it's authentication mechanism.
I have used hellojs successfully on the client side to trigger the authentication method in a separate browser window and then use the access token successfully to call my API but how do i do this from the server side?
All the examples I've seen when setting up oAuth2 involve securing an API using the OWIN middleware (e.g. with Facebook login, etc) but I need to retain the existing forms authentication and simply invoke code that calls the API and handles the access code/token etc.
If I need the backend system to make requests on behalf of a user, should I be storing the access token securely somewhere?
The simplest approach would be to have the users authenticate against B2C separately. Think of this in terms of "linking" their account in your Web Forms app to their B2C account. If you also request the offline_access from Azure B2C, you'll receive a Refresh Token that you can exchange for a valid Access Token when needed.
Ideally, you should pivot away from Forms authentication. It's a very outdated model. It may, however, be a non-trivial amount of work which is why many folks often choose to start with the "linking" strategy and only tackle Forms Auth when they're doing a larger refactoring of their app.
At my company we are developing several web applications that uses a REST API server.
First a little introduction.
The app provides the ability to manage users through the REST API and allows the users to login to the app.
Right now the REST API is for internal use only because we plan to develop more apps and communicate to the REST API as the central point of data access. We are handling the REST API authentication with a "Resource Owner Password Credentials Grant" implementation for the internal apps.
What we need is a Single-Sign on service for all the apps, we want a user to login to an app and if he/she access to another of our apps he/she will be already loged in.
We have been experimenting with the CAS protocol, with the CASino library specifically and it works great.
The problem is we don't know how to handle the flow between the apps, the REST API and the SSO service, also I don't know if there is a better choice regarding SSO services.
My questions are...
How we could handle the flow between the apps, the REST API and the
SSO service, because the REST API should be stateless it should not
communicate to the SSO service? or is there a way to communicate the
REST API to the SSO service?
Is there a better choice to implement a Single-Sign on service,
maybe OAth or OpenID and are this options suitable for REST APIs?
Thanks in advance!
Your REST API will have to talk to the SSO server to validate the Access Token, unless all the information it needs is encrypted inside the Access Token. Not sure what you mean by "flow between the apps", you should have all apps talking to a central SSO server.
When a user wants to create an account on WebApp1, the account should be created on the SSO server, either by redirecting them there or if you need a differently styled signup form for each web app, then via an AJAX call to the SSO server's REST API. I would recommend the latter as redirecting is more difficult to debug and it can make a bad user experience.
Make sure the messaging is clear, i.e. not "Sign up for a WebApp1 account", but "Sign up for a MyCompany account to get access to WebApp1".
OAuth 2.0 is very popular and people have more experience with it, so it's easier to get help or integrate with apps created by others.
The doorkeeper gem is a good server library.
OAuth 2.0 is normally used when the SSO server doesn't trust the client apps (e.g. Facebook, Twitter), but it can be implemented in such a way to skip the client authorization step (where the user is asked to approve the client app), and you can use the Resource Owner Password Credentials Grant via a REST API.
CAS is easier than OAuth. It is fairly easy to implement the basic endpoints and that way you can customize it as you wish.
I worked on a CAS-based server with a custom implementation (not sure if it was even really CAS-compliant). The authentication was done with Devise (I don't recommend Devise if you're going to customise it a lot, make your own in this case). The original flow was that the user went to the website, clicked Login/Register and then was redirected to the SSO server and after the user logged in, redirected back with a one-time ticket that the website's backend exchanged to an access token via a REST API call.
Then we added a REST API that was called from each website with AJAX. You send the username/password/captcha/etc and get back an auth token, which the site sends to its own backend. The SSO REST API can also set a cookie on its own domain, so that if the user visit another of our web apps it makes a call on pageload to check if the user is logged in. This way you're automatically logged in on every webapp without the redirect mess.
All tokens issued + the associated user info were sent to a fast Node.js app that would save them to Redis, and the app backends would call this app to validate the access tokens really fast, without putting load to the SSO Rails app.