OpenIddict Samples

repository·dev·Indexed 21 days ago

https://github.com/openiddict/openiddict-samples

A comprehensive collection of samples demonstrating OAuth 2.0 and OpenID Connect flows using the OpenIddict framework. Includes implementations for ASP.NET Core (Authorization Code Flow, BFF, ROPC, Device Flow), .NET multi-platform clients, and OWIN / ASP.NET 4.8. Features the Contruum sample specifically designed for OpenID Connect Provider Certification testing.

Tokens
3.2K
Snippets
10
Records
17
Agent score
74%

What's inside openiddict-samples

  1. Explore OpenIddict OAuth 2.0 and OpenID Connect samples

    dev

    This repository provides a collection of samples demonstrating various OAuth 2.0 and OpenID Connect flows using OpenIddict. Samples are categorized by technology stack:

    ASP.NET Core Samples

    • Client Credentials with mTLS: Aridka (uses a .NET console client).
    • Authorization Code Flow: Balosar (Blazor WASM client), Mimban (Minimal APIs + GitHub delegation), Velusia (ASP.NET Core client), Weytta (supports Integrated Windows Authentication), and Zirku (Minimal APIs with introspection and local validation).
    • Backend-for-Frontend (BFF): Dantooine (Blazor WASM + YARP) and Geonosis (Blazor Web InteractiveAuto + YARP + token exchange).
    • Resource Owner Password Credentials (ROPC): Hollastin (mTLS token binding).
    • Refresh Token Grant: Imynusoph (using a .NET console client).
    • Device Authorization Flow: Matty (using a .NET console client).
    • Conformance Testing: Contruum (Razor Pages, designed for OIDC certification).

    .NET Samples

    • Multi-platform Clients: Sorgan (Console, WinForms, WPF, and Blazor Hybrid using GitHub authentication).

    OWIN / ASP.NET 4.8 Samples

    • Authorization Code Flow: Fornax (Web Forms 4.8 + OWIN/Katana) and Mortis (MVC 5.2 + Web API 2.2).
    • Resource Owner Password Credentials: Kalarba (OWIN/Katana + Web API 2.2 + OpenIddict degraded mode).

    External Community Samples

  2. How to approach OpenID Connect certification with OpenIddict

    dev

    OpenIddict is a framework that requires custom implementation (such as an authorization controller) rather than being a turnkey solution. Because of this, a single reference implementation cannot guarantee that all user deployments will be standard-compliant.

    Recommended Workflow:

    1. Implement your custom logic using OpenIddict.
    2. Execute the OpenID Connect Provider Certification suite against your specific deployment to ensure compliance.

    For testing purposes, the Contruum sample in this repository is specifically designed to be used with the certification tool. It uses two hardcoded identities to facilitate testing without requiring full membership or consent features.

  3. Understand Arcade template shims, logic, and redirects

    dev

    Arcade's template architecture uses three types of files to manage the distinction between standard and 1ES pipelines:

    • shim: An intermediate YAML file (found in templates/ or templates-official/) that acts as an entry point. It defines the is1ESPipeline parameter (false for templates, true for templates-official) and redirects to core-templates.
    • logic: The actual base template logic, primarily located in the core-templates folder.
    • redirect: A file in core-templates that points back to specific logic files in either templates or templates-official when the logic is dependent on the shim used.

    Key Behavior:

    • Templates at the stages, jobs, and job levels are implemented as shims.
    • Templates at the steps and variables levels typically contain direct logic because they are too granular for shims.
  4. Use Open Iconic's SVG Sprite

    dev

    The SVG sprite allows you to load all icons in a single request. To use an icon, reference the sprite file and the specific icon ID using the <use> tag.

    Styling Tips:

    • Sizing: Set equal width and height on the <svg> tag.
    • Coloring: Use the CSS fill property on the <use> tag to change the icon color.
    • Best Practice: Add a general class to the <svg> tag for shared styles and a unique class to the <use> tag for icon-specific styles.
    <!-- HTML Structure -->
    <svg class="icon">
      <use xlink:href="open-iconic.svg#account-login" class="icon-account-login"></use>
    </svg>
    
    <!-- CSS Sizing -->
    <style>
    .icon {
      width: 16px;
      height: 16px;
    }
    
    /* CSS Coloring */
    .icon-account-login {
      fill: #f00;
    }
    </style>
  5. Reduce security scan overhead with multiple outputs in 1ES

    dev

    When using 1ES pipeline templates (templates-official), every publish artifact execution triggers additional security scans. To minimize this overhead, you should gather all publishing outputs into the $(Build.ArtifactStagingDirectory) and use the 1ES outputParentDirectory feature.

    Implementation Steps:

    1. Ensure your build outputs are copied to $(Build.ArtifactStagingDirectory) using a task like CopyFiles@2.
    2. Define the templateContext.outputs in your template parameters to map these files to artifact names.

    Note: Multiple outputs are only applicable when referencing templates-official.

    # azure-pipelines.yml
    extends:
      template: azure-pipelines/MicroBuild.1ES.Official.yml@MicroBuildTemplate
      parameters:
        stages:
        - stage: build
          jobs:
          - template: /eng/common/templates-official/jobs/jobs.yml@self
            parameters:
              # 1ES makes use of outputs to reduce security task injection overhead
              templateContext:
                outputs:
                - output: pipelineArtifact
                  displayName: 'Publish logs from source'
                  continueOnError: true
                  condition: always()
                  targetPath: $(Build.ArtifactStagingDirectory)/artifacts/log
                  artifactName: Logs
              jobs:
              - job: Windows
                steps:
                - script: echo "friendly neighborhood" > artifacts/marvel/spiderman.txt
              # copy build outputs to artifact staging directory for publishing
              - task: CopyFiles@2
                  displayName: Gather build output
                  inputs:
                    SourceFolder: '$(System.DefaultWorkingDirectory)/artifacts/marvel'
                    Contents: '**'
                    TargetFolder: '$(Build.ArtifactStagingDirectory)/artifacts/marvel'
  6. Choose between public and 1ES pipeline templates

    dev

    Arcade provides two distinct sets of templates based on your pipeline requirements:

    • 1ES Pipeline Templates: Use eng/common/templates-official for any internal production-graded pipelines or runs that must be managed by 1ES pipeline templates (e.g., 1ES Microbuild templates).
    • Public Templates: Use eng/common/templates for all other pipeline runs.

    Refer to azure-pipelines.yml for a templates-official example and azure-pipelines-pr.yml for a standard templates example.

  7. Understand OpenIddict support policies

    dev

    Support is primarily offered to project sponsors and regular contributors.

    General Support

    • GitHub Tickets: Users who do not contribute or sponsor may have their tickets automatically closed.
    • Private Support: Available via email at contact@openiddict.com for specific sponsorship tiers.
    • Community Support: Available on Gitter.

    Version Support

    Support is generally limited to the latest stable version of OpenIddict, with the following exceptions:

    ABP Framework Users

    ABP Framework users receive patches for OpenIddict as long as their ABP version is supported by Volosoft. For example:

    • OpenIddict 5.x is supported for ABP 8.x until November 19, 2025.
    • OpenIddict 6.x is supported for ABP 9.x.

    OpenIddict Sponsors

    Sponsorship tiers (6 through 9) provide extended support for previous major versions, ranging from 1 month up to 24 months following a new major release.