I have written REST APIs. I have users in OKTA. Does OKTA only supports OAuth token based access for REST APIs or for my REST APIs I can also use some other authentication mechanisms as well to authenticate users to APIs??
As it's your API you can protect it with whatever your want :) Some forms can be a static API token which a user would need to send you in an authorization header, or something else.
But as you have your users in Okta, it would make sense to go with a standard mechanisms like OAuth protection, where your app is registered with Okta as an OAuth service for which users would need to get an access token. Then you would ask that token to be sent in a standard Authorization: Bearer xxxxx header for it to be validated by any solid JWT verification library.
Related
I'm having a hard time figuring a good way to implement Oauth 2.0 and OpenID Connect authentication alongside an existing internal email+password authentication for a B2B Web app's API using Spring security.
We have a backend REST API that is a Spring Boot servlet application which currently authenticates users with OAuth 1.0 and the password grant. The front-end is an Angular single-page app through which users must log in with their username and password. The API's /oauth/token endpoint then delivers an opaque access token to be used for fetching secured resources that are then displayed within the app.
We'd like to add the possibility to log in using external authentication with OpenID connect, which is a perfect opportunity for switching to OAuth 2.0 and JWT tokens. Our API would then accept JWT tokens it delivered as well as external JWT tokens emitted by accepted issuers.
Reading and validating JWT tokens won't be a problem using Spring security's OAuth Resource Server. However things get complicated with how to make the classic username+password login flow work with JWT tokens.
We thought about delivering JWT access tokens the same way we used to with our old OAuth 1.0 tokens. The thing is, newer OAuth specifications advise against using the password grant, plus it simply isn't supported in the Spring authorization server project we're planning to use. The authorization-code flow w/ PKCE seems like too much for this case as we do not want the back-end API to render a login form but use credentials entered in the existing login form that is part of the single-page app.
I've read a lot about not using OAuth for 1st party login since its primary use is for external authentication, but again, that doesn't apply since we also want 3rd party authentication.
What would be a secure way to implement a Spring boot authorization server that can deliver JWT access tokens to a 1st party client in exchange for a user's credentials, all this using the existing log in page, and given the password grant type no longer being supported?
I thought about implementing a preliminary step that would be a POST request with Basic authentication to a /login endpoint that just returns a 200 HTTP status, then proceeding to the /oauth2/authorize request that would deliver the authorization code immediately without redirecting since my session is authenticated.
I'll be happy to provide more details if needed. Here are the resources I'm using for this project.
What about setting up an authorization-server capable of identity federation?
In such configuration, the authorization-server is responsible for providing with identities, proxying one or more sources (your existing user database for instance, plus maybe Google, Facebook, Github, etc.)
Keycloak does it for instance.
From the client point of view (your Angular app), the authorization-server is used to get:
access-token: put in Authorization header of requests to secured resource-server(s) (can be a JWT or an opaque string, doesn't matter, clients should not try to extract data from access-tokens)
refresh-token: send to authorization-server to renew access-token before it expires
id-token: get user-profile data (email, username, profile picture, etc.)
You should have a look at https://github.com/damienbod/angular-auth-oidc-client for connecting an Angular app to an OIDC authorization-server.
From resource-server point of view, access-tokens are the source ofr setting-up security-context, either by decoding and validating a JWT locally or with token introspection on authorization-server.
Have a look at those tutorials for such resource-servers configuration.
My aim is to authorize browsable API(first app) using the JWT token generated(second app).
I have two apps created,
1. API - has all the data
2. Authentication - generate JWT tokens after validating the user.
Now, when I try to access the API after generating the token it says,
Authentication credentials were not provided.
Trying to access the API (passing the bearer whatevertoken)
I mean, is there a way to authenticate the Browsable API using JWT token? Instead of creating a user session.
Passing Authorization header as,
"Authorization: JWT token"
authenticates the user.
But, limits me to browse the API in a browser. Is there any way we can implement Browsable API using JWT authentication?
UPDATE
A thorough reading on
Authentication classes
Permission classes
Django settings
Helped in understanding the core concepts and apply appropriate solutions.
We would like to have REST APIs with OAuth2 using our own user table for Authentication. Also, we need to allow Social Login. Below is the flow for social login,
Our OAuth
Client makes auth and access token URL for our servers to receive
the access token
Client sends access_token for further calls in the header as bearer
token
Social Login
Client makes auth and access token URL to Social Login server(For
ex,https://accounts.google.com/) to receive an access token
The client sends access_token for further calls in the header.
We have implemented our OAuth with Spring and working perfectly. We have questions on social login,
How to identify our own Oauth access token and social login access
token. We may have many social logins and we should able to identify corresponding social login.
How to validate and integrate with Spring Boot?
If the access tokens are just random strings, you probably cannot tell the issuer of the provided token and you cannot validate it.
I would suggest you to extend your OAuth2 server to accept third party providers (Google, Facebook ...) for authentication. This way would support both local and social users, but in your application, you would always deal with your own tokens. It would make the application security much easier (which usually means safer) and you could also configure your own scopes for access tokens. There are also ready to use solutions for it - e.g. Keycloak.
We are creating Spring Boot REST services that registered third parties can use.
We provided the third parties with a unique API key in JWT format, containing authorizations for that party to the services it can use.
The JWT is securely provided to the third parties and they need to include it in their requests to our API in the Authorization: Bearer header.
There exists new a use case where our API needs to call an other party's OAUTH2 authorized services. They probably are going to use the OAUTH2.0 Authorization Code Flow. This means that the third parties that are calling our API need to be redirected to the Authorization server of the other party to authenticate and get an oauth token generated.
Questions
The question/problem that we have now is, can we refactor our JWT token to include the oauth token from the other party?
And how will the flow look like then?
Or should we proceed with 2 different headers and store our API key JWT token in another header then the Authorization header?
I'm considering using authenticated encrypted JWT tokens to authenticate / authorized access to an ASP.NET Web API application.
Based on what I've read so far, it seems to me like it is an option to generate JWT tokens from a token service and pass them to Web API via the http authorization header.
I have found some good code examples on implementing the JWT creation and consumption (Pro ASP.NET Web API Security by Badrinarayanan Lakshmiraghavan).
I'm trying to understand if I need a full OAuth implementation to support this, or if I can simply pass the tokens along in the auth header.
Assuming the tokens are properly encrypted and signed, is there any inherent security flaw in keeping things simple without having to use OAuth?
Trying to keep things as simple as possible for my needs without compromising security.
It is not that you must always OAuth when you use tokens. But given the fact that your application is a JavaScript app, you would be better off implementing a 3-legged authentication. Thinktecture identity server does support implicit grant. But if the client application getting access to the user credential is not a problem for you, your JavaScript app can get the user ID and password from the user and make a token request from a token issuer ensuring the user ID and password are not stored any where in JavaScript app (including DOM). This request for token can be a simple HTTP POST as well and it does not need to be anything related to OAuth. If your end user will not enter the credentials in the client application, OAuth implicit grant is the way. BTW, you don't need to encrypt JWT. TIS issues signed JWT and that will ensure token integrity. But if you are worried about the confidentiality, you can use HTTPS to both obtain the token as well as present the token.
It looks like you don't really need auth delegation as the one provided by OAuth. Isn't HMAC authentication enough for your scenario ?. With HMAC, you will not have to deal with JWT at all. This is an implementation I made for HMAC authentication for .NET
https://github.com/pcibraro/hawknet
Pablo.