How to use the Oauth/Openid Revocation Endpoint

Follow
    Applies to:
  • Legacy SecureAuth IdP
Deployment model:
  • On Premises
  • SecureAuth IdP Version affected: All

    Description:
    This article will show you how to use the Revocation endpoint

    Cause:

    Resolution:

    The revocation endpoint works best when User Consent storage is enabled and is used with the Introspection endpoint. 

     

    Pre-reqs:

     

    1. Open the SecureAuth Admin Console.
    2. Navigate to the Post Auth page of your Oauth/OpenID realm
    3. Set Enable User Consent Storage to True
    4. Select a Consent Stroage Attribute, such as Aux ID 10

    consent.png

    5. Save the changes
    6. Click on the Data Tab and select an unused AD attribute for the attribute selected in step4. Such as houseidentifier. Tick the box to make it writable

    storage.png


    7. Save the changes

    Revocation Post:

    1. Post to https://youridp.example.com/secureauthxx/oauthrevocate.aspx
    2. Needs to be x-www-form-urlencoded
    3. Should contain the following

    client_id: The client id set in the post auth page
    client_secret: The client secret set in the post auth page
    token: a valid Access or Refresh token that you wish to revocate

    mceclip3.png

     

    Oauth Introspect:

    It's always best to Introspect the tokens that a User presents to make sure they haven't been revoked. 

    After revocation, the introspect should show as false. 

     

    1. Post to https://youridp.example.com/secureauthxx/oauthintrospect.aspx
    2. Needs to be x-www-form-urlencoded
    3. Should contain the following

    client_id: The client id set in the post auth page
    client_secret: The client secret set in the post auth page

    token: The access token you're trying to introspect. 

    mceclip4.png


    SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.
    Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.