New Okta Enhancements Help You Build Highly Scalable, Secure Apps
Application attacks are on the rise. According to F5’s The State of the State of Application Exploits in Security Incidents, 56% of the largest incidents in the last five years tie back to web app security issues. With the constant evolution of security “best practices,” it can feel near impossible to maintain the best security posture for all of your apps. Maintaining the agility to simultaneously pursue new customer-facing apps and opportunities only adds to this complexity.
To that end, we’re excited to announce several enhancements to our OpenID Connect and SAML apps to help you improve your overall app security posture. These new and upcoming security enhancements for apps enable you to
- Achieve zero downtime for apps: support for overlapping client secrets allow for seamless client-secret rotation.
- Increase security posture: support for Private Key JWT, PKCE verification, signed request objects, and per-app SAML certificates allow for security best practices within your apps.
- Enable agility: an improved, simplified admin experience makes it easy to manage applications and identity providers
Read on for next steps toward implementing these innovative features.
OIDC application client credentials management
Overlapping client secrets
OpenID Connect apps use app credentials to ensure that tokens are issued to legitimate apps—not potentially malicious clients. These credentials consist of a client identifier and a secret. Just like periodically changing passwords, regularly rotating your app's authentication client secret is a security best practice. The challenge with rotating the client secret is facilitating a seamless client-secret rotation—without downtime to your service or app.
To alleviate this challenge, Okta now offers the ability to create overlapping client secrets. This allows developers enough time to update their app instances with a new secret value while ensuring that existing requests are continually served without app downtime. Once the app developer is confident with the secret update process, they can easily log into the Admin Dashboard to disable the old client secret.
Support for private/public key pairs
Applications that handle sensitive data require advanced security protections. Okta now supports using public/private key pairs as the client authentication mechanism.
How does it work?
- The client generates a private key and stores it securely.
- The client only uploads the corresponding public key to the authorization server (Okta).
- The client authenticates by signing a JWT assertion with the private key.
- The authorization server uses the public key to validate the assertion and process the request.
Okta provides multiple out-of-the-box options to configure public/private key pairs:
- For simple development and testing use cases, you can create an OIDC app and click the Generate new key button to create a set of key pairs for your application.
- You can generate your own key pairs, then upload the public keys to Okta.
- Okta offers the unique capability to host your public keys in a URI, then paste the link to the Admin console. Okta dynamically fetches the app's latest public key, eliminating the need to manually update the public key in the Admin Console when you’re rotating the key pair. Hosting the keys in a URL, you can conveniently rotate the keys without having to update the app configuration every time. This is especially important for healthcare applications, as the recent 21st Century Cures Act mandates this. Okta offers this capability out-of-the-box.
To get started, learn more about client secret rotation and key management right here.
PKCE verification for confidential clients
You can now configure PKCE (Proof Key for Code Exchange) as an additional verification step for an OIDC app, including confidential clients. PKCE has been used to secure authorization code flow from public clients such as mobile and single-page apps. Since PKCE has effectively curbed authorization code injection attacks, it is now a mandatory requirement in OAuth 2.1.
Support for public/private key pairs and PKCE on Generic OIDC Connector
When the end-user credentials are stored outside of Okta instances, customers use Generic OpenID connect for a federated log-in experience for their apps. When interacting with identity providers in regulated industries such as government, healthcare, or financial services, customers require a higher level of security. Okta now supports the ability to
- Configure private/public key pairs for client authentication
- Send request parameters to the OpenID provider as an encoded JWT— instead of passing the parameters in the URL
- Make authorize requests with a PKCE challenge for additional security
If you’re ready to start implementing these enhancements in your OIDC apps, head over to our Documentation to get started.
SAML application enhancements
Per-app SAML certificates
SAML is a widely deployed single sign-on protocol. To ensure your SAML assertions only work with the right apps, unique signing keys are recommended for each app or service provider. Okta now offers the out-of-the-box ability to use unique pairs of signing certificates for every SAML app. Using unique certificates prevents assertion replay attacks wherein bad actors use assertions minted for other apps to gain access.
Support for Signed Request Object
Signing SAML requests ensures incoming requests come from genuine applications. Okta only accepts SAML requests signed using the certificate associated with the app integration when configured. Having signed SAML requests also resolves scenarios where the Assertion Consumer Service (ACS) URL requested after authentication can be one of several domains or URLs. When a Service Provider sends a signed authentication request, Okta can return dynamic ACS values as part of the SAML request.
For details on these features, refer to the Advanced Settings section of Create SAML app integrations using AIW.
Learn how customers like Jetblue and MLB are building highly scalable, secure apps using Okta.