Skip to content

[idea/question] Why SCIM implementations still issue API Keys rather than supporting Client Credentials? #122

Description

@eabedrapo

Reflexion:
We've been championing M2M connections using OAuth2 Client Credentials to replace the use of long-lived API keys associated to service accounts, but when we require to implement SCIM to orchestrate CRUD operations, vendors seem to support only a long lived bearer token to authenticate their endpoint.

Genuine questions:
Is this a vendor limitation that will change with the adoption of IPSIE?
Or is this a gap allowed by the ambiguous language in Section 2 of the protocol spec? (issued 11 years ago!).
Is this section being discussed by any other OIDF WGs?

Thanks.

Full disclosure:
I'm not an expert here. I've been trying to self-educate myself and I ask questions based on my limited experience as a practitioner and a leader of engineers dealing with vendors providing services to the company I work for. I don't have many opportunities to attend conferences and in-person events, and I may have missed discussions among experts that meet regularly to talk about these things. Maybe I've been very unlucky working with vendors that haven't prioritized best practices and/or a correct implementation of the standards, so my questions here might have been biased by my bad experience with multiple SCIM implementations I've seen in the last 1.5yr working in these integration projects. Thanks for understanding.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions