Hiding a SPA behind an authentication gateway? - javascript

I am building an application with the following planned login flow:
User logs in at 1.1.1.1:8080 at php web page.
php web page sends request to api at 2.2.2.2:8080 to create JWT access token
JWT access token gets sent to reverse proxy to authenticate with SPA at 3.3.3.3:8080.
It should not be possible to access the SPA frontend at 3.3.3.3:8080 without the JWT access token. If the auth is invalid they should be redirected to the php page at 1.1.1.1:8080. What free technologies exist to implement this? I was looking at nginx but it looks like it is only possible with nginx plus.

Related

AWS Load Balancer Authentication with Cognito Testing

I'd like to use an Application Load Balancer (ALB) to authenticate requests with Cognito to my node express back-end. After authenticating, the ALB maintains session with a session cookie, and will forward a few headers to the back-end in form x-amzn-oidc-* (e.g. x-amzn-oidc-accesstoken).
My application backend needs these claims to carry out requests. So how do I develop and test token signature verification locally?
Edit:
Similar question here.
Headers containing identifying information and access tokens here

How to retrieve access_token from Azure Active Directory (AAD) Web API

I am building a web app with the following properties:
The Front-end is based on VueJS
The Back-end framework is still not confirmed but it will be a RESTFul API
The users for the app will be authenticated by Azure Active Directory (AAD)
Here's what I have done so far:
I have set up a Web App/API in my AAD. Along with that following the guidelines here, I have completely secured my VueJS app and now I need to be logged in into my AAD in order to be able to use the app.
The problem now is that, the front-end is secured. But what about the backend? I am trying to get an access_token from the AAD which I can then use as an authorization header with every request to my backend later on.
Here is what I get from my AAD when I sign in using the AuthenticationContext from the adal library.
As you can see I am getting an id_token and when I use the acquireToken function of adal I get an id_token again.
Is there anything I am doing wrong here? Do I need to create another Web App/API on Azure?
How do I go about this?
Thanks!
According to official documentation and this might be your case.
"The OAuth 2.0 implicit flow in Azure AD is designed to return an ID token when the resource for which the token is being requested is the same as the client application. In other words, when the JS client uses ADAL JS to request a token for its own backend web API registered with same App ID as the client, an ID token is returned and cached by the library. Note that in this case the resource should be set to the App ID of the client (App ID URI will not work). This ID token can then be used as a bearer token in the calls to your application's backend API."
You can find more about this here!
https://github.com/AzureAD/azure-activedirectory-library-for-js/wiki/Acquire-tokens

Separated frontend with backbone.js and node.js backend token

I have separated projects,
Server side node.js with express to serve restful api but returning JSON instead html. All the examples in internet are returning html with ejs.
Frontend is and independent application with backbone and socket.io.
I want to do a login and registration page and I did it with passport.js on the server side, but I have not idea of how to send the token to the frontend and store it there to send It on every request to the server. If the user is out of session then the login page, ,must be shown.
I want a way compatible with oauth 2.0 for multiple authentication strategies.
Sorry for my English and I have a lot of dudes and I don't understand all the concepts.
Basically what you have is an API and a client, and you need two things:
The client to be able to open a session on the API.
The client to be able to embed its session credentials in every request so that the API knows who is doing the query.
First Step
For opening the session, you have figured it out: you want your API to be an Oauth Client.
So when a user wants to log in, your client will redirect it to http://api.yourserver.com/login/google which will redirect to google, which will redirect again to your API with a token that allow your API to access Google's API (hence, know who your user is).
This token cannot be used to authenticate against your API. Its only goal is to allow your API to act on the user's behalf on google services.
Second Step
Then you need to decide how will your client authenticate against your API. You can choose to use a cookie which almost everyone do (it's the sane default for express sessions).
Or, if your API is consumed by many different clients, and you don't have control over those clients, you can choose to implement an Oauth Server to protect your API.
The clients will then authenticate against your API using a "Bearer Token" (it's an HTTP header).

How to implement OAuth 2.0 like token based authentication for rest API which is accessed from mobile and javascript web applications

I need to implement authentication and authorization mechanism for my REST API. This is rest api is accessed from a mobile application and web application.
Mechanism I would like to implement:
So as per my understanding, I am using password based authentication. Mobile application or javascript web application sends username and password over HTTPS post request to obtain access token for limited time.
Problem
As access token expires every 1hr or so. End user is again requested to enter username and password. This is not acceptable.
If we increase the time of the token for longer period, then if someone gets handle on token they can have access to Rest API for more time. As the web application is javascript application, its easily available in plan text.
So I am trying to understand how are applications like facebook and twitter implement authorization for their native mobile applications. Do they remember access token for ever by storing in local storage. So that if some malicious application have root access to android phone can access the tokens.
What are the improvements to above mechanism to make it work for both for both standalone web application which is developed in javascript and android application?
Access tokens are indeed meant to be short lived. To maintain authorization for a long period of time, OAuth2 has something called "refresh tokens".
If the provider supports it (and both Google and Facebook do), the OAuth2 consumer can request a refresh token in addition to the access token during the initial flow (Google calls that "offline access" I believe). The access token is used normally but when it expires, the consumer can request a new access token using its credentials and the refresh token.
See Google's doc for more info: https://developers.google.com/accounts/docs/OAuth2WebServer#offline.

Down-scoping Oauth access-token, possible?

I am developing an open source javascript project. It has client side database, Oauth Connect login and bear-token base access to cross domain resource servers like (GData, Google cloud storage, AWS via proxy). The main focus is on consumer cloud data (you know, developer got free data storage).
The main goal to provide database to the web app without using backend server. It is achieved by keeping Oauth 2 refresh token in the server, providing access token to the web app so that it can populate its client side database, directly from resource servers. Dumb proxy server may be necessary for updating back to the resource server.
Login user may share his data to other login user. Server provides access token as necessary. In that case I wish to down-grade the access token. Generally once a new user start using the app, the server request off-line multiple scopes read-write grant. Currently, I as far I can understand a refresh token can generate access token of exact scopes.
Is that possible to request a down-graded access token from an offline refresh token? Even down grading from read-write to read-only is very useful.

Categories

Resources