I would like to use my API website for authentication & authorisation of users and ideally keep my UI site purely static content (html, js, css).
I have configured ServiceStack's OAuth & OpenId (and credential/basic) providers, so they answer to api.mysite.com/auth/{provider} requests
I would like to be able to users of www.mysite.com to be able to authenticate and then make calls to the API site via ajax.
The BootstrapApi example project - although very useful - demonstrates the API & website running on the same domain.
Is this possible/secure with a static javascript client?
Could I share a cookie between sub-domains?
Could I return the access token to the client and have use it to calculate an Authorization header before each request?
To address your questions -
Is this possible/secure with a static javascript client? Yes
Could I share a cookie between sub-domains? Yes
Could I return the access token to the client and have use it to calculate an Authorization
header before each request? Sure but you may as well just use the
built in auth cookie.
It's just a matter of setting up your cookies on the top level domain, similar to what's shown # ServiceStack - Authentication for domain and subdomains
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.
i want to reach a confidential client for my backend-system.
The SPA is an angular app. The backend a spring-boot application with different rest-endpoints which stores the objects in a postgres-db.
Actual my SPA got a login page which are connected to the oauth-server. My SPA is currently a public client (client-credentials are stored there). I want to reach a confidential client.
I attached a picture above. The SPA triggers the login. The backend now takes over the authentication, so that the backend is now the client. The backend receives the access token and stores it in a session db. The backend then issues an httponly cookie to the SPA so that the session is secured accordingly.
Is my architecture possible? Are there any examples somewhere? I have no experience in session management and want to programming as less as possible to avoid mistakes and vulnerabilities.
Thanks for help!
yes, you can setup a reverse proxy in the backend that will perform the OAuth 2.0 BFF task, for example see:
https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/
https://github.com/zmartzone/mod_auth_openidc/wiki/Single-Page-Applications
https://curity.io/blog/token-handler-the-single-page-applications-new-bff/
Do I need to activate CORS on my API's server (i.e. return appropriate header in response) if the client connecting to it already provides Basic Auth information.
After lots of googling, the relation between CORS and Basic Auth from the client is still not clear to me . (if there is any relation...)
Does it make sense to have to enable CORS on the server if it already requires Basic Auth from client?
Is Basic Auth supposed to "by-pass" CORS, meaning the server shouldn't have to provided CORS headers as the request from the client is authenticated?
Are CORS and Basic Auth not related at all?
Thanks!
Do I need to activate CORS on my API's server (i.e. return appropriate header in response) if the client connecting to it already provides Basic Auth information.
Yes (assuming you want to allow cross-origin requests).
Auth is there to make that that when Alice's browser requests some data from Bob's website, that Alice is authorised to get that data.
The Same Origin Policy stops Mallory's website from using JavaScript to make Alice's browser request that data from Bob's website and then pass it back to Mallary without Alice knowing.
CORS lets you selectively disable the Same Origin Policy so that Mallory's website can be given permission to get that data.
Are CORS and Basic Auth not related at all?
Correct. They are not.
Further reading
In previous versions of ASP.NET you got authorization and authentication out of the box from the default template.
I have a Web API application and three or four well defined clients that will consume it and I need to secure it.
I read about OpenID and OAuth but they seem like an overkill for my problem.
What's the simplest way to achieve that?
These would be the 3 best solutions if you require security:
WEB API browser client: Implicit OAuth 2 flow
WEB API Application client: OAuth2 code flow
(With OpenId)
OR: Cookie Authentication with Cross-site request forgery protection. (Default template MVC 6 website template)
If your application is public, I would use at least one of these, otherwise it depends on how secure your data must be.
Well, it depends on your scenario. If you don't need authentication (because it's a server-to-server scenario), use a security token as described below. If you need authentication of the user, you may use Basic or Digest security combined with HTTPS.
In a security token scenario, the client simply has to add the token to the request headers and the server needs to validate the token. Make sure the requests transit as HTTPS to make sure the token is encrypted. Remember, this method is only valid if you know the applications that will access your API will be in a secure environment (another server, for example). Otherwise, I would go for another solution.
Am using web api 1. For Get apis i can enter the url (servername:portno/api/Controllername/apiname/) in the browser address bar and call the api directly from browser and get the json output
This seems to be a security issue. How can I restrict this url hit?
But I can not be using any authentication or authorization in the web api as its handled from UI side (mobility)
There are multiple ways how to secure your Web API. And actually you don't need some "HTML UI" to do them.
You can have either HTML UI where your user will HTTP POST form and will exchange login/password to some token (session id, OAuth single sign-on token etc.).
You can HTTP POST form without user as well, just from your code. And result will be the same, credentials are exchanged to some tokens, which are included in each next requests in HTTP headers
You can programatically restrict access to your API from some IP adresses or services
Anyway all the ways are require to implement authentication and/or authorization techniques. And what you see in HTML UI is only top of the iceberg and can be done without user.
When you need to close HTTP requests from browser just check HTTP header with browser agent.
Either authentication or just special handler for browser agent HTTP header, you will require at least MessageHandlers for both.
Your URL to start deep dive into WebAPI authentication http://www.asp.net/web-api/overview/security