I am trying to learn how to use OKTA as a token issuer for an application.
I am a bit confused as to the connection between a custom authorization server and an Okta application. How do I assign an okta application to the authorization server so it will be able to issue tokens for that application with the applications scopes?
I don't see any api call to do it in the server's api here: https://developer.okta.com/docs/reference/api/authorization-servers/
Is it even true that an application needs to be assigned to an authorization server, or is it done in some other way?
The way to assign an application to an authorization server is by using an access policy on the server which defines the app
Related
If I deploy my service in (cloud run) as no-allow-unauthenticated, I can add a user with cloud run invoker role to secure the API. Then user can login to gcloud and set the token in the authorization header to access the service.
My question here is, can I send the Google authorization token via a different header instead of authorization?
The reason why I am using google token is to protect staging(development) env to only allow access to the dev team. My Spring Boot app doesn't need any protection under google platform as it has its own oAuth mechanism - authorization header is being used by spring boot.
Thanks
After a lot time spent, I decided to configure spring boots to deal with another Authorization header name. I left Authorization for GCP.
I am currently developing using spring security oauth2.
Currently, the frontend is SPA, and it is developed as react that operates with client side redering.
My rest api has the spring security starters libraries. But I don't know how to use oauth2 flow provided by spring.
So my question is: Can I use spring security as IAM to protect my web and api?
Does spring security have the known oauth2 grants and how use them ?
Implicit grant
Client Credentials Grant
Password grant
Don't use implicit grant
It is not recommended to use the implicit flow (and some servers prohibit this flow entirely) due to the inherent risks of returning access tokens in an HTTP redirect without any confirmation that it has been received by the client.
source: https://oauth.net/2/grant-types/implicit/
With implicit grant, access token is returned immediately without an extra authorization code exchange step. This extra step is usually performed in your backend.
Web > token > Api
SPA frontend and its Rest Api is a very common approach, used since simple startups until big companies. The flow summarized is:
Your users will start the web application.
As they were not signed in before, you web app will show them a login screen (a page provided by the authorization server).
After authenticating, a consent form is showed to the user.
After user consent, the authorization server will send you an authorization code.
The web app will exchange this code for a token.
After getting back this token, the web app store it in the client(browser) and send it as a header when apis needs to be consumed.
Your private rest apis must validate if token of the web app (header) is valid by sending it to one endpoint of the authorization server
If token is valid, your api rest is allowed to respond to the web client. For instance a json with products, employes, some update of customer order details, etc
For this flow to work, you will need:
web spa with a hint of backend. Backend is required because you cannot have a proper user session in static solutions like apache or nginx.
authentication and authorization server: Known as identity and access management (IAM) or some third app which provide you the basic oauth2 endpoints to manage a proper security for your apps.
your apis: foo-api , bar-api, baz-api, etc
spring security
In the minimal scenario in which:
you will have only one web + one rest api, and nothing more in the future (mobiles, iot, etc)
you don't have an authentication/authorization server
you have a mix of functional apis (employee, products, etc) and its security (spring-security) in just one artifact
you don't need user session in your web
you don't need a logout feature
Flow could be reduced to:
Your users will start the web application.
As they were not signed in before, you web app will show them a login screen (a page provided by spring-security).
After authenticating, a consent form is showed to the user.
After user consent, the authorization server will send you an authorization code.
The web app will exchange this code for a token. Since your api is using Spring security, the token generation is covered.
After getting back this token, the web app store it in the client(browser) and send it as a header when apis needs to be consumed.
Your private rest apis must validate if token of the web app (header) is valid by sending it to one endpoint of the authorization server I think the spring security chain filters handle this.
If token is valid, your api rest is allowed to respond to the web client. For instance a json with products, employes, some update of customer order details, etc
Here some samples of token generation and protected endpoints with spring security. I will try to upload a ready to use sample:
https://www.freecodecamp.org/news/how-to-setup-jwt-authorization-and-authentication-in-spring/
IAM
If you will have more applications and complex scenarios in the future, I advice you to choose some open-source iam like:
Glewlwyd,Keycloak,OAuth.io,ORY Hydra,SimpleLogin,SSQ signon,
Commercial services like:
Auth0,Curity Identity Server,FusionAuth,Okta,Red Hat Single Sign-On,cidaas.
Or try to develop a new one using pure spring-security
Lectures
Some recommended answers with more oauth2 details:
https://stackoverflow.com/a/62123945/3957754
https://stackoverflow.com/a/62049409/3957754
https://stackoverflow.com/a/57351168/3957754
https://stackoverflow.com/a/63093136/3957754
https://stackoverflow.com/a/54621986/3957754
https://stackoverflow.com/a/63211493/3957754
I am working through a process of validating the JWT after OKTA Login. I have a SPA Sample SPA Site that handles user login and calling an API.
SPA SITE
User Logins into OKTA
Obtains a JWT
Passes JWT to a .NET Web API (hosted on my own server not at OKTA).
WEB API: This accepts the JWT and needs to validate it.
Per OKTA I need verify the JWT through an Authorization Server. I setup the Authorization Server but I cannot see where the two features (shown on the images) are located on the SPA API or the Auth Server. This includes a URL that is required that follows the format of xxxx.okta.com/AS/{key}
Is there something that has to be enabled that is not enabled in my OKTA Account? I think so but what is it? OKTA support states that everything is enabled and confirmed this is a good code sample (GitHub) to use.
The Image Below should appear after setting up the SPA App. I cannot find this feature under the SPA or under the Auth Server. It does not seem to exist anywhere on OKTA. This is why it seems something is not enabled on my Dev account, or this documentation is outdated?
SPA Code Sample (includes the images below from the PDF) https://github.com/oktadeveloper/okta-oauth-spa-authjs-osw
I see that under the Security menu item -> API.
Also, when I had my app OpenID Connect enabled, I used well-known endpoint:
GET /.well-known/openid-configuration to get "jwks_uri", I used this url to self-verify the JWT token at the API level.
OKTA confirmed the code sample and documentation is out of date. They have no ETA to any updated samples and could not provide any documentation to help. This was via a response on a support ticket. Well already then, time to look at Azure.
So we have an authentication server where the UI application gets the access token and then it communicate with API server, it's all good. Now we are building a third application which needs SSO to authenticate the same user and that is fine too.
However, there are scenarios where this third application needs to use some resources on the API server which, from my understanding, we need to get a token from auth server using client-id/secret and then send the request with the access token. This seems ok too, however I am not sure how API server is going to authorise that token (a hint on this would be great).
But the main problem is we want this request to be sent on behalf of the user. This is because API server needs to audit all user's activities. How can we achieve this using Spring Boot/OAuth2 and JWT Token?
I went through documentation and I know about #EnableOauth2Sso #EnableAuthorisationServer etc. but this scenario is not clear and I'm not even sure it's been implemented in Spring or not.
If there is no implementation for this scenario, what do you recommend? Any experience you have had on this, can you please share?
Your API server plays the role of a Resource Server. There is an annotation designed for that purpose: #EnableResourceServer. Your client app then will consume this resource using the handy OAuth2RestTemplate.
There are two approaches to properly configure the Resource Server and get this working:
Have the public key directly in your resource server app: this way when the client app try to use a token provided by the authorization server to get a resource from the Resource Server, this will verify if the token is valid by itself.
Configure the resource server to ask the authorization server if a given access token is valid and depending of the response it will allow or decline to get the resource.
I have posted a sample app on github using the first approach. There you can see the interaction between the Authorization Server, the Client and the Resource Server, as well as all the configurations you need for this implementation. Hope it helps you.
I want to use native applications and a web server to get refresh tokens to use for some operations (on google drive). Client ids and secrets have been generated for both the native and the web application using the Google developer console.
I'm trying to generate authcodes from the native applications and exchange them from the web server for access/refresh tokens using a script heavily inspired from the java example. The main difference is that there is two GoogleAuthorizationCodeFlow (they represent the native and server parts):
One using the native application's id and secret and used for generating the authorization code.
One using the web application id and secret and used to exchange the authorization code for credentials.
Such procedure does however result into a 401 Unauthorized exception.
When using for both GoogleAuthorizationCodeFlows the same credentials, either the creds of the native application or the web application ones, the process succeed and returns a refresh token.
How can I use the authorization code from a native application on a web application to generate access tokens? Is there a way to use the web application id and secret to exchange the authorization code or must be procedure be finished using the same credentials used for generating the token?
The reason that it is not working is that Authentication is linked to the client id and client secret.
When a user authenticates they are authenticating that client id / client secret pair. You cant just take the Refresh token or the Authentication code and use it with a different client id and secret they wont match and it wont work and you will get a 401 Unauthorized exception.
your on the right track with
How can I use the authorization code from a native application on a
web application to generate access tokens?
What you need to do is create Client ID for native application just one and use the client id and client secret for both your native application and your web application.
Web vs Native
The only real difference between a Client ID for native application and a Client ID for web application is the Redirect URI. The Redirect URI just tells the Authentication server where to return the authentication to. In the case of a website that's easy its the web page where you handle the code most of the time this is the same ip address. In the case of a native application there is no way to know this so the server sends the information back to the requesting ip. Beyond that there is really not difference, except maybe that Google likes to know if its a website or a installed application running the code maybe. So you can use a native client id on a web application the server will just return it to where ever it asked.
Security
There are probably some security considerations with using a native one on a web application, I guess someone could potentoaly get a hold of it and send info with your client id. TBH I find the chance of this limited.