Can we have an OIDC client application (Apache Web+OIDC library) running in DMZ that is taking care of user authentication and authorization through Okta API OIDC integration? Basically, the idea is to have the user authenticated and authorized to access the OIDC Client app, Receive the access token and send it to the backend application.
This is all trying to restrict the request reaching backend application server before it is properly authenticated and authorized and also to cut all the outbound calls from backend application server machine.
Does this approach has any downside or security concerns? Any other additional validation to be taken on backend application to verify the access token to make sure it was issued by Okta Custom API Authz server and came from the trusted client? Please suggest.
My $0.02… Take with a grain of salt since I don’t know all the details of what you’re trying to do.
Can we have an OIDC client application (Apache Web+OIDC library) running in DMZ that is taking care of user authentication and authorization through Okta API OIDC integration? Basically, the idea is to have the user authenticated and authorized to access the OIDC Client app, Receive the access token and send it to the backend application.
This is all trying to restrict the request reaching backend application server before it is properly authenticated and authorized and also to cut all the outbound calls from backend application server machine.
Yes you can. Not sure if you should.
Does this approach has any downside or security concerns? Any other additional validation to be taken on backend application to verify the access token to make sure it was issued by Okta Custom API Authz server and came from the trusted client? Please suggest.
Some things you should consider:
Using a Web Server on DMZ means that you’re relying on perimeter security. You should implement the proper network controls for that (firewalls, intranet, etc).
You also loose some deployment flexibility when you implement this, since your app must live only behind the firewall.
If you port authorization to your Web Server (check access token scopes), you are under risk of having to reconfigure/restart the server every time a new scope comes up. This brings A LOT of work on sysadmin.
If your app is already working with OIDC/OAuth and is parsing id and access tokens, it’s performing 90% of the job. Adding the code for checking the token is not much (and probably way less than deploy new web servers). You can also rely on Okta SDKs to help you with that (Go Home | Okta Developer. you can click a programming language to check the SDK available).
IMO If you’re adding a Web Server on the DMZ only to improve security, you should instead consider adding rules to your firewall to filter bad incoming requests and create a restrictive rule for outbound requests. For OIDC/OAuth, the only outbound reqs your app will make are to get tokens, refresh tokens, and introspect users. You can create an outbound rule in your firewall to limit those (outbound only to https://myorg.okta.com/oauth2/myAuthzServerId).
I guess the Web Server/DMZ strategy is a good option only when you’re trying to protect legacy apps that are not compatible with OIDC and OAuth.