Are the limitations of using OAuth2.0 instead of the API Token documented?

[suhasgaddam-trueaccord]

I'm trying to use okta_app_oauth, okta_app_saml, and okta_app_group_assignment with [clientId, privateKeyId, privateKey, scopes = [ 'okta.apps.read', 'okta.groups.read', 'okta.apps.manage', 'okta.groups.manage'] ].

I keep running into some variant of the following:

failed to get groups claim for OAuth application: the API returned an error: Invalid session, Status: 403 Forbidden

This error seems to be from here: https://github.com/okta/terraform-provider-okta/blob/master/sdk/app_oauth_group_claim.go#L32-L45

I noticed that api is under /internal. Is it even possible to do the following with an OAuth 2.0 client application?

[monde]

Hi @suhasgaddam-trueaccord I'd need to see an example of the config you are using that is getting this error to try and reproduce it myself. Can you post up the most minimalist example that reproduces the error?

Unfortunately, some shortcuts were taken in the past where the provider is calling /internal endpoints that are considered private and can change without notice. We are in the process of eliminating calls to /internal endpoints to and making all API calls throught okta-sdk-golang .

[100xff]

Hi @monde, it seems like this is still a problem in 4.1.0.

Here's a MWE.

resource "okta_app_oauth" "test_group_claims" {
  label       = "Test Group Claims"
  type        = "web"
  grant_types = ["authorization_code"]

  groups_claim {
    type        = "FILTER"
    filter_type = "EQUALS"
    name        = "groups"
    value       = "example"
  }

  redirect_uris  = ["https://example.com/"]
  response_types = ["code"]
}

I can plan this using an admin API token, but when I try to use application credentals I get the same 403 error in response to GET /api/v1/internal/apps/{application_id}/settings/oauth/idToken.

I tested this with every API scope, so can rule out this being a non-obvious permission problem.

Provider configuration

provider "okta" {
  org_name = var.org_name
  base_url = var.base_url

  client_id   = var.client_id
  private_key = var.private_key

  scopes = [
    "okta.agentPools.manage",
    "okta.agentPools.read",
    "okta.apiTokens.manage",
    "okta.apiTokens.read",
    "okta.appGrants.manage",
    "okta.appGrants.read",
    "okta.apps.manage",
    "okta.apps.read",
    "okta.authenticators.manage",
    "okta.authenticators.read",
    "okta.authorizationServers.manage",
    "okta.authorizationServers.read",
    "okta.behaviors.manage",
    "okta.behaviors.read",
    "okta.brands.manage",
    "okta.brands.read",
    "okta.captchas.manage",
    "okta.captchas.read",
    "okta.certificateAuthorities.manage",
    "okta.certificateAuthorities.read",
    "okta.clients.manage",
    "okta.clients.read",
    "okta.clients.register",
    "okta.deviceAssurance.manage",
    "okta.deviceAssurance.read",
    "okta.devices.manage",
    "okta.devices.read",
    "okta.domains.manage",
    "okta.domains.read",
    "okta.emailDomains.manage",
    "okta.emailDomains.read",
    "okta.eventHooks.manage",
    "okta.eventHooks.read",
    "okta.events.read",
    "okta.factors.manage",
    "okta.factors.read",
    "okta.features.manage",
    "okta.features.read",
    "okta.groups.manage",
    "okta.groups.read",
    "okta.idps.manage",
    "okta.idps.read",
    "okta.inlineHooks.manage",
    "okta.inlineHooks.read",
    "okta.linkedObjects.manage",
    "okta.linkedObjects.read",
    "okta.logStreams.manage",
    "okta.logStreams.read",
    "okta.logs.read",
    "okta.myAccount.appAuthenticator.maintenance.manage",
    "okta.myAccount.appAuthenticator.maintenance.read",
    "okta.myAccount.appAuthenticator.manage",
    "okta.myAccount.appAuthenticator.read",
    "okta.myAccount.email.manage",
    "okta.myAccount.email.read",
    "okta.myAccount.phone.manage",
    "okta.myAccount.phone.read",
    "okta.myAccount.profile.manage",
    "okta.myAccount.profile.read",
    "okta.networkZones.manage",
    "okta.networkZones.read",
    "okta.oauthIntegrations.manage",
    "okta.oauthIntegrations.read",
    "okta.policies.manage",
    "okta.policies.read",
    "okta.principalRateLimits.manage",
    "okta.principalRateLimits.read",
    "okta.profileMappings.manage",
    "okta.profileMappings.read",
    "okta.pushProviders.manage",
    "okta.pushProviders.read",
    "okta.rateLimits.manage",
    "okta.rateLimits.read",
    "okta.reports.read",
    "okta.riskProviders.manage",
    "okta.riskProviders.read",
    "okta.roles.manage",
    "okta.roles.read",
    "okta.schemas.manage",
    "okta.schemas.read",
    "okta.sessions.manage",
    "okta.sessions.read",
    "okta.templates.manage",
    "okta.templates.read",
    "okta.threatInsights.manage",
    "okta.threatInsights.read",
    "okta.trustedOrigins.manage",
    "okta.trustedOrigins.read",
    "okta.uischemas.manage",
    "okta.uischemas.read",
    "okta.userTypes.manage",
    "okta.userTypes.read",
    "okta.users.manage",
    "okta.users.read"
  ]

  max_api_capacity = 60
}

[ctdhr]

Hey @monde, I can confirm I'm getting a similar behaviour as @100xff with v3.46.0, v4.0.2 & v4.2.0.

Any terraform plan or apply fails on this resource, when using client_id & private_key authentication in the provider.
A standard API token works perfectly well.

resource "okta_app_oauth" "vault_sso_app" {
  label       = "HashiCorp Vault"
  type        = "web"
  grant_types = ["authorization_code", "implicit", "refresh_token"]
  redirect_uris = [
    "http://localhost:${var.cli_port}/oidc/callback"
  ]
  response_types            = ["id_token", "code"]
  consent_method            = "REQUIRED"

  # Redacted stuff here

  groups_claim {
    type        = "FILTER"
    filter_type = "STARTS_WITH"
    name        = "groups"
    value       = "service/"
  }
  login_mode   = "SPEC"
  login_scopes = ["openid", "email", "profile"]
}

Provider config is the same as the one here.

[monde]

We should put some gating around the groups_claim argument if the sdk client is doing authentication with private key.

Okta internal reference: https://oktainc.atlassian.net/browse/OKTA-638990

[erkiesken]

We are also hitting this issue. We've opted to use private key auth with our Okta TF automation tooling, and have the same error pop up now. And we can't easily switch to use api tokens, since those expire automatically in too short a period for our use case.

[monde]

I put guards on the problematical groups claim in okta_app_oauth that will prevent this blocking error for operators using OAuth 2.0 auth. It's in this PR which will be released this week #1691

Also these documentation updates:

commit 01e7c7e3974cf087fd059bf9574ac9a31787e275
Author: Mike Mondragon <mikemondragon@gmail.com>
Date:   Thu Aug 31 15:41:37 2023 -0700

    Guarding internal API calls when always_apply in okta_profile_mapping is
    utilized when OAuth 2.0 authentication is utilized.

 website/docs/r/profile_mapping.html.markdown | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

commit e256d99830c2e73f2de799437be283ce2162aec0
Author: Mike Mondragon <mikemondragon@gmail.com>
Date:   Thu Aug 31 15:26:45 2023 -0700

    Clarify resource okta_security_notification_emails is not OAuth 2.0
    authentication compatible.

    Closes #1568

 website/docs/r/security_notification_emails.html.markdown | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

commit ba8f2329c5fc1e7eb56af75410b7897c4bd5d0bd
Author: Mike Mondragon <mikemondragon@gmail.com>
Date:   Thu Aug 31 15:23:37 2023 -0700

    Clarify resource okta_rate_limiting is not OAuth 2.0 authentication
    compatible.

    Closes #1568

 website/docs/r/rate_limiting.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 5fd356e4237ced7eca5ace996e92dc48b21cc0c8
Author: Mike Mondragon <mikemondragon@gmail.com>
Date:   Thu Aug 31 15:13:47 2023 -0700

    OAuth App's group claim is guarded from usage when OAuth authentication
    is used.

 website/docs/r/app_oauth.html.markdown | 2 +-

[thatguysimon]

Hey @monde
Is it possible that the guards added don't work on pre-existing resources?
After upgrading from 4.0.2 to 4.4.0 we started getting this error as well, and this is despite the fact that we're not even using the groups_claim argument at all in our resource configuration. Even adding it to ignore_lifecycle doesn't help.

resource "okta_app_oauth" "my_app" {
  label               = "My App"
  logo                = "${path.module}/assets/images/logo.png"
  type                = "web"
  issuer_mode         = "DYNAMIC"
  grant_types = [
    "authorization_code", "refresh_token"
  ]
  redirect_uris = [
    ...
  ]
  response_types = ["code"]

  lifecycle {
    ignore_changes = [
      logo, groups_claim,
    ]
  }
}

╷
│ Error: failed to get groups claim for OAuth application: the API returned an error: Invalid session, Status: 403 Forbidden
│ 
│   with okta_app_oauth.my_app,
│   on applications.tf line 15, in resource "okta_app_oauth" "my_app":
│   15: resource "okta_app_oauth" "my_app" {
│ 
╵

Downgrading back to 4.0.2 resolves the issue.

[monde]

@thatguysimon I see I missed a guard, I'll do a quick release by EOD

[monde]

@thatguysimon give https://github.com/okta/terraform-provider-okta/releases/tag/v4.4.1 a try, thanks

[thatguysimon]

@monde Works, thanks!

[monde]

Closing -> Previously I put guards around the (verboten) internal API calls that not supported by SDK clients auth'ing with OAuth2.0 . I also documented any affected resource in the public docs https://registry.terraform.io/providers/okta/okta/latest/docs . I want to reiterate we shouldn't be calling internal API endpoints, our intention is to get rid of them as equivalent public API endpoints come online.