I have a SPA that calls a PHP backend (based on Symfony currently for proof of concept).
Authentication for this application is based upon an Azure Active Directory, and all azure users are matched against the local application user table on their email address and OID - if not registered locally then a local account is created for them with basic privileges.
For authentication, a call to the backend which then redirects to Azure to authenticate, and then the access token is returned. Instead of re-inventing my own auth token system in the backend, can I just get the SPA to pass the Azure access token in the API calls and validate it on the backend, letting the SPA deal with refreshing the token as and when required?
Cheers
Yes - in this partial SPA model you will typically need to store a refresh token in an http only secure cookie. When the web UI calls an API and gets a 401 expired response it will need to call the back end to refresh the token.
Related
I want to use azure AD as authentication.
If user who is in certain organization logged in from SPA, and give access token to backend, then I want to permit access from SPA.
So, I want to check if token passed from SPA is valid or not.
How can I do this?, Or Can I do this?
I want to build backend server with node.js app, and deploy backend app to app service or Azure Container Registry.
I think bearerStrategy would work.
Ref https://github.com/AzureAD/passport-azure-ad
BearerStrategy uses Bearer Token protocol to protect web resource/api.
It works in the following manner: User sends a request to the
protected web api which contains an access_token in either the
authorization header or body. Passport extracts and validates the
access_token, and propagates the claims in access_token to the verify
callback and let the framework finish the remaining authentication
procedure. On successful authentication, passport adds the user
information to req.user and passes it to the next middleware, which is
usually the business logic of the web resource/api. In case of error,
passport sends back an unauthorized response.
In the past, there was an ADAL version for node apps. I don't know if it's still valid or not, but here are useful links:
https://medium.com/#liangjunjiang/verify-and-decode-azure-activity-directory-token-bc72cf7010bc
https://learn.microsoft.com/en-us/azure/active-directory/develop/authentication-flows-app-scenarios
Application Implementation Details -
My application is structured as follows:
MVC Web Application hosted on Azure Web App.
Angular JS is used at the client side integrated with the web application.
Services are hosted on Azure Service Fabric Cluster.
Authentication is happening using Azure AD.
Service Fabric APIs are hit from angular js files as follows -
After authentication from Azure AD, the bearer access token is received.
This token is added as Authorization header in the AJAX request from js.
The token is retrieved from the header in the API and validated.
Due to the above implementation, the bearer access token is retrievable from the developer tool in browsers. And using this token, unauthorized requests can be made to the APIs from tools like Postman etc. The default expiry of this token is 60 mins.
Problem Statement -
I need to invalidate the token once the user logs out of the application. This is to prevent unauthorized access to the APIs.
Question -
Need input on how to invalidate or expire this token? Or is there any other approach which can be used to solve this problem?
s> Question - Need input on how to invalidate or expire this token? Or is
there any other approach which can be used to solve this problem?
Upon the token is issued, you cannot invalidate the token until it expires. If you could make sure the use time, you could configure the token lifetime that is less than 1 hour. How to configure token lifetime, please read here.
I'm new to using Azure Active Directory authentication with a Web API. Right now the login page on my Single Page Application simple directs the user to the Microsoft login page where they enter their credentials and then are redirected back to my SPA. Upon the redirect the access token is now part of the URL. Is it possible to get that token via JSON rather than part of the URL? Is that a security risk making the token visible to user like that? If there is no other way to get the token what's the best way of processing that? Should I read the URL and pull the token from there and then redirect the user again to the actual website?
You have to be mindful in implicit flow the token will still be maintained at the client site (local storage normally). So even if you are hiding the token from URL , you still will be storing at client side and that's one of things you have to manage in SPA. You will have to send token with every HTTP request to your web api to get that authenticated on that end.
In implicit flow tokens are shortlives and you can't issue refresh token for longer period of access. For this kind of flow you need to use official library (ADAL.js)
https://github.com/AzureAD/azure-activedirectory-library-for-js
More resources
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-implicit-grant-flow
You can use ADAL.js library to acquire the token. There is a pre defined function which you have to call after the Ad authentication or at the beginning check if you are logged in, you can use isauthenticated function to check if you have already logged in, and use getaccesstoken function to acquire the token after authentication.
I'm working on adding google login to my web app. It's a RESTful app, so once a user is logged in, each individual request must be authenticated with a token.
Currently, I create my own tokens using JWT. I can add useful information to the token object to help with state management.
My question is: once I add google as an authentication provider, do I then need send every request to Google to be authenticated, rather than authenticating it on my own server? Do I then lose the ability to customize the content of the token?
With external authentication providers, is it normal to manage separate JWTs for calls to your RESTful API?
Normally, you'll have the login action use the third party to identify the user. Your internal code will probably create/store/fetch an app local user profile of some sort, and you'll create your JWT based on that. Further calls to your API bearing a valid token are then trusted to have already been authenticated and therefore need no further calls to the auth provider.
We have a web service, which currently uses Basic Auth over https to authenticate user requests. We also have a website which uses the service, and a native Windows client, which also uses the web service. I've read about OAuth, and it seems like it's always used for giving or getting access to external resources, i.e. delegation, but I'm trying to understand if it's a replacement for Basic Auth.
I'm not quite sure how all the parts fit together. Do you use Basic over https to the website to retrieve a secret and then have the javascript which is making requests to the REST services authenticate to the web service using OAuth instead of Basic?
It seems that at some point the user needs to enter their username and password into a form. I'm not sure what typically happens next. Is this even a use case for OAuth?
If you have local database accounts for the users (Resource owners) then you can replace the basic authentication with the one of OAuth flow named "Resource Owner Password Credentials" flow.
It is very simple flow where you issue HTTP post to an end point specified in your HTTP server usually named /token The content-type for this HTTP Post action is x-www-form-urlencoded, so the post body will contain something like this grant_type=password&username=Taiseer&password=SuperPass
One the request is sent to the /token end point the server will validate the user credentials against your database store, and if all is valid it should generate a token (signed string) which contains all the claims for this resource owner (user). Then your client application should present this token in the Authorization header with each call to any protected end point using bearer scheme.
This token expires after certain period and you can configure this from the AuthZ server. You can read my detailed blog post Token Based Authentication to get more details.