I am building SPA with thin server architecture (in my case it mean: webserver role restricted to server static content and route xhr with backend REST services):
so far I failed to find any example that provide user authentication scheme that cover my requirements, when it comes to user authentication all what I see webserver (server side code) involved whether its php/nodejs/asp.net..etc.
I want to build the authentication with zero dependency on server side code that belong to webservers:
details:
user requested login.html.
NGINX served the user request.
user supplied credentials and submit.
Ajax XHR received by NGINX and routed to the Authentication backend REST service.
authentication backend service validated the request and returned response that include session cookie/access token/api key.
Ajax XHR received the response through NGINX, then what? how should I proceed? below are current ideas I have:
a. in many examples (including instagram): window.location.reload();. but in my case reload login.html will not cause NGINX to forward the user to the landing page unless it maintain the authentication logic! so how I can pass this obstacle?
b. in case I redirect the user to landing.html, NGINX will serve it. but again that's not acceptable because every resource request (except login.html) must be validated first (I mean both authentication and authorization).
I hope the question is clear now. I think if NGINX can be configured to pass every request to the authentication backend REST service before it go to the original destination, big part will be resolved though it might be big overhead for auth service!
Your best option here is to use X-Accel-Redirect. This will allow you to pass your requests to the authentication service and then in the authentication service you can run your auth logic and if successful set the X-Accel-Redirect header so that when nginx gets the response it will perform an internal redirect to the resource that you actually want to call. If authentication fails your service can reply with a 401 and not set the header so nginx will provide the proper response to the client.
Your other option, which will be more daunting, is to implement this as a custom Lua module.
Related
I have a NextJS frontend and Golang backend architecture with an authentication system using JWTs and an internal user/password database. I'm adding OAuth sign-in in addition to the JWT system, but all API calls will still be maintained using JWTs. I have a working prototype that uses the following OAuth flow:
User is directed to a NextJS page that displays various login options as buttons.
When a provider is chosen, the user is redirected to the backend at /auth/provider where they are then redirected to the provider with all required keys and callback links.
User logs in at the provider and the redirect is triggered to /auth/provider/callback.
The backend server retrieves the user data from the callback and connects the user email to the internal user data for generating a JWT.
The backend returns a page that stores the JWT in local storage and redirects to a NextJS page.
The NextJS page can then use the stored JWT to make API calls.
An additional step could be to exchange the JWT for a new, non-stored JWT or session cookie if the JWT is used twice (potential XSS attempt) and the new JWT is invalidated.
The above method works, but requires a locally stored JWT. Is this a concern, and is it possible to complete the final steps without the need for a locally stored JWT.
Does this flow make sense or am i going about it all wrong? Would swapping to PKCE be overkill?
For the current prototype I'm using the github.com/markbates/goth example code running as the golang backend and a basic NEXTjs server
In effect you have a form of backend for frontend there. It is worth browsing OAuth for browser based apps a little similar to section 6.2 of the above doc.
One option might be to host the backend at a URL like https://api.example.com, then make it write cookies for the Next.js app, hosted at a URL like https://www.example.com.
In this way the backend and frontend parts of the OAuth flow are decoupled, and you also avoid locally stored JWTs. Note the same domain prerequisite, needed for the cookie to be considered first-party, and therefore avoid being dropped by browsers later.
We are using Okta Customer Identity with our application. The challenge with our architecture is that each user gets their own server and subdomain, which is a little weird for Okta, because each redirect URL needs to be provided as part of the application configuration. As we add new users, the list of redirect URLs continues to grow, one per user machine. Their API is not really designed for this, so we have to write the complete list of redirect URLs with every change.
We would like to find a way to use a proxy for the Okta authentication, so that we can just have a single redirect URL for the Okta application configuration. But we're using https://github.com/okta/okta-spring-boot, and we're not really sure how to make it work with a proxy.
If we set up an HTTP proxy using -Dhttp.proxyHost=my.proxy.host -Dhttp.proxyPort=8080, that's going to affect all HTTP traffic, which is not acceptable.
Is there a way we can use an HTTP proxy purely for the Okta auth only, leaving all other HTTP traffic unproxied?
Is there something we can do with the Okta Spring Boot library that would make it possible for all user machines to share a common proxy machine?
The final alternative would be to write some "active" proxy code that runs on the proxy which handles the requests and forwards them on to Okta. It would have to introspect the Okta response and pass it back to the right user machine.
Is there a way to do #1?
Failing that, is there a way to do #2?
If neither of those are possible, are you aware of an existing implementation of #3?
I have stumbled upon a problem with Spring Security and Angular.
On my BE (Spring Boot application), there are defined OAuth2 providers, such as Google, GitHub and Facebook.
My BE works fine with this providers, since I can authenticate on the desired providers.
The problem is when I try to send the principal object to the FE (Angular 6 application).
I get undefined value when i try to subscribe the value from the rest endpoint.
I assume this is due to the Spring Servlet creating a new thread for the login request.
I am doing my login request from the Angular app.
I did watch dozens of tutorials and rad so many articles, but I just can't find the answer. If it's possible for you to share some code on how it is done, or give me a link, since for sure I am making a silly mistake and can't seem to find the answer here.
Thanks for understanding, have a good day.
:)
I am assuming that you are using the Authorization Code flow from your BE to authenticate the user that interacts with your FE Angular application (you in your example). Otherwise, you would be trying to authenticate the BE Client with the Client flow and you wouldn't need to return the "principal object" to the FE application. If my assumptions are correct... read on.
The Authorization Code flow goes as follows:
1) The user somehow selects an Authentication provider (ex: Google) and that selection is returned to some endpoint in the BE as a non-authenticated request..
2) The BE Client receives this request, preferably intercepted by a filter and, since the request is not authenticatedd, redirects the browser to the selected auth provider's authorization endpoint.
3) The user then proceed to authenticate against that provider which, upon succesfull authentication, returns a response that redirects the browser to a BE Client endpoint. That redirect holds a parameter that provides a code that the BE Client will use to get an idToken representing the user. At this point, it is important to note that the browser has not been returned any response for this redirect.
4) The BE Client then proceeds to send a regular HTTP request to the provider's token endpoint along with the received authorization code. The provider then returns the idToken an HTTP response directly to the BE Client. All this is happening while the browser is still waiting for the response to the last redirect.
5) The BE Client then process the idToken (verification, validation, user details, session etc) and only then, will finally send the response to the browser patiently waiting since the code redirect. That response may provide a header or a cookie with a sessionId or token (your choice) that the FE application will be able to read or use for the given purpose.
This flow is relatively easy to implement and requires minimal SS configuration. You must keep the BE Client auth endpoint with permitAll() otherwise, you would not be able to trigger this flow. Also, make sure that, once the FE app. has received the header/cookie, all subsequent calls shall be processed as "authenticated calls". Finally, make sure to document yourself on the perils of stateless sessions as well as cookie security and always use HTTPS.
Jake.
We are working on an existing application where web services (tomcat) as well as UI (nginx) applications are hosted on separate containers. One of the service application is used for sending login request (SAML request) to identity provider (ping). Here are the steps for user login to the system:
User loads the application (domain URL: https://ui.domain.com), it loads the UI where it checks for logged in user (JWT token string generated for user/role) on local storage and when not found, it redirects to ping (IDP) for authentication.
Once authenticated with ping, it calls the spring controller which is configured for the success URL on service application (https://api.domain.com/auth-service/auth).
This controller service (/auth), gets the SAML response sent by ping and processes it further to get user details and generates the JWT token for the user and redirects the user to UI (https://ui.domain.com).
Problem Statement:
To pass the token to UI, the JWT token string is added to URL by using
redirectAttributes.addAttribute(“auth-token”, token);
With the above, it shows up in the address bar like: https://ui.domain.com/?auth-token=
This has raised a concern with respect to security as the token is displayed on address bar and exposed which can be decoded to get user information.
Current Approach (tried):
Before redirection from controller to UI, tried to set cookie
Cookie cookie = new Cookie(“auth-token”, token);
cookie.setMaxAge(-1);
cookie.setPath(“https://ui.domain.com”);
response.addCookie(cookie);
However we couldn’t find the cookie from UI.
We tried to set it to response header too.
response.addHeader(“auth-token”, token);
Since it is a redirection, the adding to response doesn’t help.
Further trials:
We are also putting a thought about changing the approach of authentication controls where after ping authentication is done, the success URL can be replaced with UI url rather than service URL, i.e.
Current: saml.sso.default-success-url= https://api.domain.com/auth-service/auth
Proposed: saml.sso.default-success-url= https://ui.domain.com/
With the above, the SAML response supposed to go directly to UI (after ping authentication is successful).
However we couldn’t get the response in UI and it also behaves like ping is doing a redirection to UI and due to the same reason, UI doesn’t get it.
Any ideas and suggestions over this would be great.
I have two Spring boot applications one is a client UI app and the other acts as an Authorization Server (using spring security oauth, implicit flow and form login).
When the two applications run on localhost (different ports) I can see the following flow:
The client makes a request to oauth/ahthorize to retrieve a token.
Since the client is not authenticated the server responds with a 302 redirect to its login form, setting also two cookies (XSRF, JSESSIONID).
The user enters his credentials and a POST is performed in the login form. Since the two apps run in localhost the two Cookies are sent in the POST request.
This way, the server retrieves the SavedRequest for this JSESSIONID and performs a redirect to the saved client url, as expected.
The problem is when running the two applications in different domains (I am trying to run it in Pivotal Web services environment).
The JSESSIONID cookie is not sent on POST of the login form.
This makes sense because the cookie was set for the client domain, whereas the login form is in a different domain and does not have access to the cookie.
This has as a result that the server does not find a SavedRequest object to retrieve the redirect URL
of the client and it redirects to the root of the server (/)
What am I missing?
EDIT: here is the POST on the login page on localhost (working scenario):
and here is the POST when domains are different (not working):
EDIT 2: Here is the authorize request, which is made to the client domain (and proxied to the server through Zuul: