FusionAuth
    • Home
    • Categories
    • Recent
    • Popular
    • Pricing
    • Contact us
    • Docs
    • Login

    Client secret hashed in source identity provider

    Scheduled Pinned Locked Moved Solved
    Q&A
    entities client creds
    1
    2
    10.6k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • danD
      dan
      last edited by

      We're migrating from an identity provider (Duende) that hashes the client secret when the client credentials grant is used.

      How can we migrate these secrets to FusionAuth entities?

      --
      FusionAuth - Auth for devs, built by devs.
      https://fusionauth.io

      danD 1 Reply Last reply Reply Quote 0
      • danD
        dan @dan
        last edited by

        No perfect options, but a few workarounds possible

        • a connector-like proxy which would intercept Client Credentials requests from their customers and use business logic to validate the client secret against the stored Duende hash.
        • stand up a simple proxy in front of the Duende that logs the plaintext client secrets for a period of time before migration (protect these logs of course)
        • go to each client and ask them to use a new FusionAuth specific client secret (analogous to resetting user passwords)

        More details on the first option. It requires these steps/prereqs:

        FusionAuth Entities Setup

        • The customer should create new FusionAuth Entities that correlate to the Client ID of all APIs and services currently associated with Duende. For now, let FusionAuth generate a random Client Secret.
        • Custom Attribute for Migration: Store a custom attribute such as migration: false on entity.data for all newly created Entities.

        Migration Steps

        • API/Service Requests Token: The API or service calls Duende's token endpoint.
        • Proxy Interception: The customer's proxy intercepts the client credentials request and searches FusionAuth Entities to find the matching Entity by Client ID.
        • Migration Check: Use an if/else logic to check if migration: false exists for this client ID. If so, the proxy service proceeds with the client credentials request to Duende using the Client ID and Secret (in plain text).
        • JWT Validation: If Duende responds with a JWT, this confirms the Client Secret is correct. The proxy service discards Duende's JWT and then calls the Entity API to update the correct Client Secret and set migration: true on the entity.data object.
        • Complete Migration: The proxy service calls FusionAuth's token endpoint to complete the Client Credentials grant. The proxy service then returns a JWT to the end customer’s API/service, migration is complete.

        Which of these make sense depend on how many clients you have, your dev teams bandwidth, and your security posture.

        --
        FusionAuth - Auth for devs, built by devs.
        https://fusionauth.io

        1 Reply Last reply Reply Quote 0
        • danD dan has marked this topic as solved on
        • First post
          Last post