Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API is capable of creating invalid api keys #1675

Open
lingwooc opened this issue Apr 11, 2022 · 3 comments
Open

API is capable of creating invalid api keys #1675

lingwooc opened this issue Apr 11, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@lingwooc
Copy link

API is capable of creating invalid api keys

Description

I think this is a bug in your api, I've also reported it here FusionAuth/terraform-provider-fusionauth#126. In any case the api shouldn't be capable of creating an invalid api key.

I found the problem in the https://github.com/gpsinsight/terraform-provider-fusionauth. If you use that you can create an api key like this:

resource "fusionauth_api_key" "key_name" {
  description = "some description"
  key         = xxxxxxxxxx
}

You get an api key created which always gives a 401.

The terraform provider uses your go client and the key bit of code is here. If you don't define any specific permissions then the code looks like this. The fusionauth documentation suggests "An Empty permissions object mean that this is a super key that authorizes this key for all the endpoints." https://fusionauth.io/docs/v1/tech/apis/api-keys#create-an-api-key So this should be fine.

	ak := fusionauth.APIKey{
		Key:      data.Get("key").(string),
		TenantId: data.Get("tenant_id").(string),
		MetaData: fusionauth.APIKeyMetaData{
			Attributes: map[string]string{
				"description": data.Get("description").(string),
			},
		},
	}

If you request the api key using the api to inspect it:

{
    "apiKey": {
        "id": "xxxxxxxxxxxxxxxx
        "insertInstant": 1000000000,
        "key": "xxxxxxxxxxxx",
        "keyManager": false,
        "lastUpdateInstant": 1000000000,
        "metaData": {
            "attributes": {
                "description": "xxxxxxxxxx"
            }
        },
        "permissions": {}
    }
}

The problem is the existance of the "permissions": {} key. If you edit the api key in the fusion frontend and resave (no changes) the "permissions": {} part disappears and the api key starts working.

POSTing to api/api-key

{
  "apiKey": {
    "key": "super-secret-key",
    "metaData": {
      "attributes": {
        "description": "my super secret key"
      }
    },
    "permissions": {}
  }
}

Creates the same probems so I assume this is what the go client is doing.

The issue appears to be the api doesn't handle the no permissions==all permissions condition properly. That, in itself, is probably a mistake. Absence of permission shouldn't really imply permission, you need another field.

Affects versions

1.33-1.36.0 (at least)

@robotdan
Copy link
Member

robotdan commented Apr 15, 2022

Thanks for reporting. Kind of working as designed... but perhaps not the right design. We'll review this one and see what we can do.

Internal:

Since each library may handle JSON serialization differently we should probably ensure that we can identify an empty permissions object and treat it just as we would if the permissions were not provided at all. These seem to be equivalent things. This is likely an issue in libraries other than Go.

@theogravity
Copy link

theogravity commented Jul 11, 2022

Just spent a good few hours troubleshooting in another GitHub issue around an API key that led back to this ticket. It would be nice if we can't solve the root cause, that we at least inform the user in the FusionAuth UI that the key currently has no permissions set with appropriate actions to take.

@Aaron-Ritter
Copy link
Collaborator

Aaron-Ritter commented Apr 8, 2024

FusionAuth/terraform-provider-fusionauth#126 this is still an issue with 1.49.2. And as mentioned already it's hard to spot, especially as it looks like everything is correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants