I am authenticating against an OAuth2 service that provides me 3 endpoints:
http://bobsoauth.com/oauth2/authorize
http://bobsoauth.com/oauth2/token
http://bobsoauth.com/oauth2/userdata
This service DOES NOT issue JWTs.
I need to use an Angular client application, connecting to a Spring Cloud Gateway, which in turn connects to multiple Spring Boot microservices.
Without JWTs, can I still use a token relay setup between the gateway and the microservices?
Without JWTs, you'll have to configure your resource-servers with token introspection (http.oauth2ResourceServer().opaqueToken() instead of http.oauth2ResourceServer().jwt() in spring-security conf). This is far less efficient than JWT decoding because each micro-service has to submit token to authorization-server for each and every request it processes.
Sample here: https://github.com/ch4mpy/spring-addons/tree/master/samples/tutorials/resource-server_with_introspection
The endpoint is usually called introspect, but I guess you'll have to figure out a way to use userdata in your case.
Have your Angular application authenticate against your authorization-server, and use the gateway just to forward Authorization header.
For Angular, I use angular-auth-oidc-client. Just put in the conf the URLs you mentioned in your question.
Related
So, I have 3 microservices and only 1 of them is used for Authentication - it uses ASP.NET Identity.
I am issuing a token every time successful login occurs, which contains claims such as Id, Username, Balance (money), Roles.
When this JWT is created how can I pass it to other APIs? Is it necessary to use API Gateway or not? Is it bad practice to store it in local storage?
If it is not necessary, can I store this JWT as Cookie and pass it to my other APIs?
And if so -> how can I create some kind of session in my other APIs, depending on that cookie?
I am very confused on 2 main topics - how other APIs will know about this token and how in each API I can create authenticated/ authorized session, because most of the tutorials use Postman and on each request they pass this auth/ bearer token. But this is not applicable in real world situations, at all.
Instead of creating JWT auth in every API, First implement API
gateway and intergrate JWT stuff in that API Gate way.
API gateway will authenticate all api calls and will send requests
according their endpoints.
In my real scenario we are Used Ocelot API gate way and it is
open source.
I've been going through this tutorial which shows how to secure a single page application using several scenarios going from simple to our own Authorization Server that delegates authentication to a provider. The first scenario uses the Authorization Code Grant to log the user in.
Suppose we replace Facebook's OAuth Server with our own in this case and configure it to return a JWT token.
Which OAuth flow should the SPA use if it wants to use the JWT token to secure requests through an edge server that load balances between resources servers?
Also how should spring boot / spring security be configured if we want to use the JWT token to replace the replace the default JSESSION and CSRF support in spring? IIUC the JWT token can be used as a replacement to both of these features.
Update
Based on Manish's answer assuming we are using OAuth 2 implicit flow we:
Put the #EnableResourceServer annotation on the Resource Server
Use an OpenID Connect client to implement the implicity flow
So once this is done are POST request secure assuming each request includes the JWT token as a Bearer Header, or do we need to also configure CSRF?
It will depend on how much your application is sensitive to security but Implicit flow is recommended for pubic client (SPA).
Tutorial is based Authorization Code flow and if you will replace Facebook with your STS, it will still use Authorization Code flow because #EnableOAuth2Sso store the JWT token on server and send the cookie to browser and it also uses refresh token to get the new JWT token. It is a customize flow to implement the Authorization Code flow with public client (SPA) based on API gateway pattern.
To implement the implicit flow - Do not use the #EnableOAuth2Sso at server side, just expose the REST API and secure it with #EnableResourceServer. And you need to use the oidc-client to implement the implicit flow link is here https://github.com/IdentityModel/oidc-client-js
CSRF protection is only required if you will store JWT token or session identifier in the browser's cookie.
I'm trying to use the #EnableOAuth2Sso along with #EnableResourceServer annotation to relay in coming Authorization tokens to upstream services. I can't seem to configure it properly. I don't want or need to really configure the internal oauth2 client to retrieve a token, it should always pull the token from the incoming request. Is this possible to do?
I have an admin-console for an existing service that I want to provide access to by adding login, using our company's OAuth 2.0 service. I want to use Apigee here, so that the web-app with the admin-console does not have to implement the login-logic.
My idea was to use AuthorizationCode flow and let Apigee manage the tokens and I looked into https://github.com/apigee/api-platform-samples/tree/master/sample-proxies/oauth-login-app, but I really can't see how our existing OAuth service fits in.
Is there a sample like that? Perhaps using Google's or Facebook's OAuth service to authenticate the user?
First, Apigee needs to be a proxy into the admin-console. This means that all traffic to the admin-console has to go through Apigee. Otherwise, you won't be able to enforce authentication.
Second, there are a couple different options for integrating with the external oauth 2.0 service. Apigee has the ability to store an external access token and use it as its own, or Apigee can generate a token and store the external access token as a custom attribute.
High level thoughts on how the Apigee proxy could look like:
ProxyEndpoint - endpoint exposed to clients connecting to admin console
TargetEndpoint (not shown in that oauth login-app example) - endpoint for the actual admin console
The flows that execute in the Apigee proxy before sending the request to admin-console will need to implement logic that checks an authentication token. If it's valid, let the request pass onto the TargetEndpoint (admin-console). If the request isn't valid, step through logic that goes calls the external oauth 2.0 server's auth code flow. This will require the following:
Apigee needs to be registered with external oauth 2.0 server.
Logic needs to be built in this proxy to support the redirection based flow of authorization code grant_type (obtaining auth code, receiving the auth code, obtaining token --> all while being redirection based and transparent to user).
In addition to #2, Apigee will need to store the external token as custom attribute and expose the apigee token, or store the external token for verification purposes later on. http://apigee.com/docs/api-services/content/authorize-requests-using-oauth-20 (see Delegating token management). After the token is stored, you'd need to respond with another 302 redirect to the initial uri + token so the request can pass through to admin-console as an authenticated request.
#2 isn't exactly straight-forward and there won't be an example proxy that shows this implementation. If the oauth 2.0 service supported a password grant, it may simplify the implementation, but allows the credentials to pass through apigee and not directly with the authorization server.
I'm struggling to decide how best to add authentication and authorisation to my SignalR service.
At the moment it is hosted in Owin alongside a WebApi2 web service. I use OAuth2 bearer tokens to authenticate with those, and it works perfectly. However, I wonder if they're suitable for SignalR?
My client is JavaScript based, and SignalR uses WebSockets if available. This means I can't use the Authorization header. I figured out that I can supply the token using the qs property before I connect. But of course an OAuth2 access token will expire (and relatively shortly in my implementation). I assume that updating the qs property won't make a difference once connected (particularly with web sockets).
I suppose my question is what is the best way to supply a security token, ticket, or any kind of authorization information to SignalR? Preferably a way that can be consistent on both my WebApi and SignalR, but I am looking to know how I should be doing it.
Thanks
It's been sometime now - but we used to look for the auth cookie in the signalR request to ensure that only a signed in user can subscribe to signalr notifications.
It didn't handle the case where the token expired - since the cookie was checked only on connect. This wasn't a problem for us.