Guide
TrainingSupportCommunity

Policies can’t be removed from OIDC clients

Suggest Edits

One of the hallmarks of ​Akamai​'s Hosted Login solution is flexibility. In fact, there can be times when it seems like Hosted Login is infinitely flexible: you can change the look and feel of your Hosted Login screens; you can modify the text of your transactional email messages; you can enable and disable two-factor authentication. In short, you can do a lot of things to make Hosted Login look, and function, exactly the way you want it to.

But that doesn't mean that Hosted Login doesn't have some boundaries and that it doesn't have some things that are off-limits. For example, some Identity Cloud customers have raised concerns because they couldn't figure out how to delete login policies or token policies from their OpenID Connect (OIDC) clients. Why have these organizations been having problems deleting these policies from their OIDC clients? There's actually a good reason for that: once assigned, you can’t remove token policies or login policies from an OIDC client. In this article, we'll examine this issue in a little more detail.


Token policies

We'll start out with token policies, because that's an easy one: you can't have an OIDC client that hasn't been assigned a token policy -- period. And that makes sense: one of the main jobs of an OIDC client is to obtain access tokens, either user access tokens (public clients and confidential clients) or administrative access tokens (configuration clients). An OIDC client that didn't have a token policy, and couldn’t return access tokens, wouldn’t be especially useful.

That's why you can't create an OIDC client without assigning that client a token policy. That's also why you can't remove a token policy from an OIDC client; if you try that all you'll do is generate an error similar to this one:

{
    errors: (tokenPolicy,) field required
}

Of course, you can always use the OIDC Configuration APIs to assign a different token policy to a client: if you don't like Token Policy A then assign the client Token Policy B or Token Policy C. But you can' remove Token Policy A and leave the client without an assigned token policy.


Login policies

Unlike token policies, it's possible to create an OIDC client without assigning that client a login policy. This is sometimes done when creating configuration clients: clients used to obtain the administrative access tokens needed to call the OIDC Configuration APIs. Because they aren't involved in user logins and registrations, configuration clients don't really need a login policy.


📘

True, configuration clients don't need a login policy; however, it's perfectly fine if they have one. What defines a configuration client isn't the lack of a login policy; instead, configuration clients are defined by:

  • The fact that they're confidential clients and, as a result, have both a client ID and a client secret.

  • The fact that they've been assigned a token policy that retrieves administrative access tokens rather than user access tokens.


Like we said, it's possible to create an OIDC client that doesn't have a login policy assigned to it. However, if a login policy is assigned to an OIDC client there’s no way to remove the login policy. Similar to token policies, you can assign a different login policy to the client, but you can't remove the login policy. 

For example, consider the following confidential client, which has been assigned the login policy 07ccc9dc-3072-4059-9c46-6ccd5fb9ffe8:

{
    "id": "cd17aee4-0c8b-4dff-aa41-dff8875482b8",
    "name": "User Schema Client",
    "redirectURIs": [
        "http://127.0.0.1",
        "https://localhost:3001/redirect_uri",
        "https://oidc-playground.akamai.com/redirect_uri",
        "https://identitydocs.akamai.com"
    ],
    "loginPolicy": "07ccc9dc-3072-4059-9c46-6ccd5fb9ffe8",
    "tokenPolicy": "a7f902b3-6e63-4f60-87a6-6cf5a1bc8ff4",
    "type": "confidential",
    "_links": {
        "self": {
            "href": "/config/e0a70b4f-1eef-4856-bcdb-f050fee66aae/clients/cd17aee4-0c8b-4dff-aa41-dff8875482b8"
        },
        "application_client": {
            "href": "/config/79y4mqf2rt3bxs378kw5479xdu/clients/5663cb83xve8fr97356s66eqrnq3g52p"
        }
    }
}

Suppose we use the Configuration APIs to try and remove the login policy. To do that, we use the PUT method and we leave out the loginPolicy property in the body parameter of our API call:

{
    "id": "cd17aee4-0c8b-4dff-aa41-dff8875482b8",
    "name": "User Schema Client",
    "redirectURIs": [
        "http://127.0.0.1",
        "https://localhost:3001/redirect_uri",
        "https://oidc-playground.akamai.com/redirect_uri",
        "https://identitydocs.akamai.com"
    ],
    "tokenPolicy": "a7f902b3-6e63-4f60-87a6-6cf5a1bc8ff4",
    "type": "confidential"
}

In theory, and because loginPolicy isn't in the body parameter, we would expect the login policy to be removed from the OIDC client. And, sure enough, when we make the API call that call succeeds with a 201 Created status code. However, if we then look at the updated property values for the client, the login policy (which we were hoping to delete) will still be there:

"loginPolicy": "07ccc9dc-3072-4059-9c46-6ccd5fb9ffe8",
"tokenPolicy": "a7f902b3-6e63-4f60-87a6-6cf5a1bc8ff4",
"type": "confidential",

The same thing happens if we try setting the value of the loginPolicy to null:

"loginPolicy": null,

Again, the API call succeeds with a 201 Created status code. But, once again, the login policy doesn't change:

"loginPolicy": "07ccc9dc-3072-4059-9c46-6ccd5fb9ffe8",
"tokenPolicy": "a7f902b3-6e63-4f60-87a6-6cf5a1bc8ff4",
"type": "confidential",

Before you ask, setting the loginPolicy property to an empty string ("") doesn't work, either. In this case, the API call fails with the following error:

{
    "errors": "('loginPolicy',) value is not a valid uuid. ('loginPolicy',) value is not none"
}

The fact of the matter is that nothing works: no matter what you do, you can't remove a login policy from an OIDC client. It just can't be done. All you can do is assign a different login policy to the client.

But, again, that’s not a problem: login clients (both public and confidential) have to have a login policy, and, even though they don't need them, it's perfectly fine for configuration clients to have a login policy. You say you have a configuration client that's been assigned a login policy? That's fine: your configuration client will retrieve administrative access tokens for you regardless of whether or not it's been assigned a login policy.

Updated 11 months ago