{"id":36900757,"url":"https://github.com/zntrio/solid","last_synced_at":"2026-01-12T15:46:50.027Z","repository":{"id":40444154,"uuid":"268514989","full_name":"zntrio/solid","owner":"zntrio","description":"An OIDC authorization server building blocks with security and privacy by design philosophy.","archived":false,"fork":false,"pushed_at":"2024-06-17T09:05:05.000Z","size":2014,"stargazers_count":24,"open_issues_count":5,"forks_count":5,"subscribers_count":3,"default_branch":"main","last_synced_at":"2024-06-19T02:05:44.142Z","etag":null,"topics":["attestation","cwt","framework","golang","jwt","oauth","oidc","oidc-client","oidc-server","paseto","pkce","privacy"],"latest_commit_sha":null,"homepage":"https://zntr.io/solid","language":"Go","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/zntrio.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":".github/CODEOWNERS","security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2020-06-01T12:24:37.000Z","updated_at":"2024-06-17T07:29:03.000Z","dependencies_parsed_at":"2024-06-17T08:25:28.534Z","dependency_job_id":"c01d8fd9-69e8-4e1a-8a3d-7ddca7eaf45c","html_url":"https://github.com/zntrio/solid","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/zntrio/solid","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zntrio%2Fsolid","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zntrio%2Fsolid/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zntrio%2Fsolid/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zntrio%2Fsolid/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/zntrio","download_url":"https://codeload.github.com/zntrio/solid/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/zntrio%2Fsolid/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28341832,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-12T12:22:26.515Z","status":"ssl_error","status_checked_at":"2026-01-12T12:22:10.856Z","response_time":98,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["attestation","cwt","framework","golang","jwt","oauth","oidc","oidc-client","oidc-server","paseto","pkce","privacy"],"created_at":"2026-01-12T15:46:49.913Z","updated_at":"2026-01-12T15:46:50.004Z","avatar_url":"https://github.com/zntrio.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# SolID\n\nAn OIDC authorization server building blocks with security and privacy by design\nphilosophy.\n\nThis will not provide a full-featured standalone OIDC Server but a limited and\nsecure settings according to your use cases :\n\n* `online users` using `authorization_code` flow with mandatory PKCE via Pushed\n  Authorization Request with state enforcement;\n* `machine-to-machine` using `client_credentials` based on asymetric\n  authentication schemes;\n* `devices and constrained environments`, you know for IO(v)T (Internet Of vulnerable Thing);\n* `offline users` using `refresh_token` flow for application that need to\n  `act as an online user but without its online interaction`.\n* `impersonation / delegation` using `token_exchange` flow fro resource server\n  who wants to access authenticated external resource on behalf of the subject\n  with a restricted resource level privilege set.\n\n## What and Why\n\nI have been developing OAuth/OIDC/UMA providers since 2012, in multiple\nlanguages and environments. `People generally don't understand` OIDC flows.\n\n\u003e It's like driving a car that requires you to know how engine work and how\n\u003e the car is built. But the only thing you want is to drive your car.\n\nOAuth / OIDC is often criticized in favor of SAML, but implementations are more\nvulnerables than the protocol itself. OAuth is just offered as a developer\nframework, but it's true to say that not all developers are aware of security\nproblems.\n\nImplementations are done by developers that don't have/take the time to browse\nthe specification maze, they read them quickly with their own belief in mind.\nAs a consequence the specifications are not understood but barely interpreted,\nthat will produce faulty implementations.\n\n\u003e Also security products are often associated with [NIH](https://en.wikipedia.org/wiki/Not_invented_here) syndrom.\n\nWhat I observed in real life:\n\n* Not using `authorization_code` because it doesn't have user/password in the\n  flow;\n* `client_credentials` grant type to be used as `customer credentials` like\n  `password` grant type but for external customer user access (login form with\n  client credentials);\n* Using `client_credentials` from a JS public UI (hardcoded client_secret);\n* Dynamic authorization application based on token claims without signature\n  checks;\n* Authentication based on the fact the you can retrieve the token ... not\n  validating token content (Token is here =\u003e You are admin);\n\nMany OIDC providers give you a lot of features that you have to understand and\nchoose to maximize your security posture. So that your security posture is\ncorrelated to your understanding of OAuth and OIDC and their implementations\nin the product.\n\n\u003e I don't like this idea to be honest.\n\nI understand the requirements of commercial products to have a wide compatibility\nmatrix, but by allowing insecure settings for one client you can compromise the\nthe whole platform, and also lose the customer inside the `feature fog`.\n\nBut OAuth / OIDC specification are only tools in a toolbox, and they need to be\norchestrated in a proper way to provide a simple, efficient and secure service.\n\nThat's the reason why I've started this project as an OSS project, to provide a\nsimple and solid implementations of 4 OAuth flows.\n\n## Objectives\n\n* Enforce OIDC features as a complete suite according to selected use-case;\n* Provide a complete toolchain to enforce security and privacy without the\n  complete knowledge of all related protocols;\n* Enhance security posture based on security objectives not the understand of\n  security protocols;\n* Provide a battle-tested framework;\n* Provide a wire protocol decoupled framework, OIDC is tighly coupled to HTTP but\n  it can be easily decoupled to become portable between other wire protocols (CoAP);\n\n## What is not\n\n* A complete OIDC compliant server. By making some **optional** and **recommended**\n  parameters as **required**, `solid` can't pass the OIDC compliance tests;\n\n## Getting started\n\nI made sample server and various integrations inside `examples/` folder.\n\n## Features\n\n### Protocol changes\n\n* `PAR+DPoP+JARM` is enabled and enforced for `authorization_code` flow;\n* `hybrid` flow is not and will be supported; Web applications must use server\n  side component (or lambda) to negociate authorizations; By design, your\n  client-side application code (JS) should not be exposed until you are identified;\n* Only response_type `code` will be supported to enforce server-side negociation;\n* `PKCE+Nonce` is enforced by default for all client types during `authorization_code`\n  flow;\n* `authorization_code` flow could not be started by the `user-agent`, as the\n  default behavior, the `client` must use PAR protocol to retrieve a `request_uri`\n  that will qualify and start the `authorization_code` flow;\n* Asymetric authentication methods are enforced by default;\n* No `HSxxx` / `RSxxx` support as JOSE signature algorithms;\n  * `HSxxx` doesn't provide digital signature;\n  * `RSxxx` uses RSA algorithms that needs to have high computation to improve\n    security protection level so that it will be more difficult for constrained\n    environment (IoT) to have same security protection level as a normal application;\n  * Only `elliptical curves` involved algorithms will be used;\n* `access_token` / `refresh_token` are `hybrid` tokens so that they embed protocol\n  validation details (expiration, etc.) without any privacy related info (sub).\n  These informations are referenced via an embeded `jti` claim that will address\n  an AS-only accessbile record that will contains extra data;\n* `audience` parameter is mandatory for request that need `scope` in order to\n  target the corresponding application. This will allow various validations between\n  `client` and `application`, and `consent` management;\n* `PAR` must use JWT encoded request payload to due request registration.\n\n### Framework\n\n* OAuth Core\n  * [OAuth 2.1](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1) - \u003chttps://oauth.net/2.1/\u003e\n  * [OAuth 2.0 Security Best Current Practice](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics)\n* OAuth Extensions\n  * Discovery\n    * [x] [RFC8414 - OAuth 2.0 Authorization Server Metadata](https://tools.ietf.org/html/rfc8414)\n  * Identity authentication\n    * [ ] [Nonce pattern authenticator](https://curity.io/resources/learn/nonce-authenticator-pattern/)\n  * Client authentication\n    * Asymmetric authentication\n      * [x] [RFC7523 - JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants](https://tools.ietf.org/html/rfc7523)\n      * [x] [RFC7521 - Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants](https://tools.ietf.org/html/rfc7521.html)\n      * [x] `private_key_jwt` - \u003chttps://oauth.net/private-key-jwt/\u003e\n      * [x] `attest_jwt_client_auth` - [OAuth 2.0 Attestation-Based Client Authentication](https://datatracker.ietf.org/doc/draft-looker-oauth-attestation-based-client-auth/)\n      * [ ] `tls_client_auth` - [RFC8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens](https://tools.ietf.org/html/rfc8705)\n  * Grant Types\n    * [x] `client_credentials` grant type\n    * [x] `authorization_code` grant type\n      * [x] [RFC7636 - Proof Key for Code Exchange by OAuth Public Clients](https://tools.ietf.org/html/rfc7636) - \u003chttps://oauth.net/2/pkce/\u003e\n      * [x] [RFC9126 - OAuth 2.0 Pushed Authorization Requests (PAR)](https://tools.ietf.org/html/rfc9126.html) - \u003chttps://oauth.net/2/pushed-authorization-requests/\u003e\n      * [x] [RFC9101 - The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)](https://tools.ietf.org/html/rfc9101) (JAR)\n      * [x] [JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)](https://openid.net/specs/openid-financial-api-jarm.html)\n      * [x] [RFC9207 - OAuth 2.0 Authorization Server Issuer Identification](https://tools.ietf.org/html/rfc9207.html)\n      * [ ] [RFC9396 - OAuth 2.0 Rich Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9396)\n    * [x] `refresh_token` grant type\n    * [x] RFC8628 - `urn:ietf:params:oauth:grant-type:device_code` grant type - [rfc8628](https://tools.ietf.org/html/rfc8628)\n    * [x] RFC8693 - `urn:ietf:params:oauth:grant-type:token-exchange` grant type - [rfc8693](https://tools.ietf.org/html/rfc8693)\n    * [ ] `urn:openid:params:grant-type:ciba`grant type - [OpenID Connect Client Initiated Backchannel Authentication Flow](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html)\n  * Resource\n    * [x] [RFC8707 - Resource Indicators for OAuth 2.0](https://tools.ietf.org/html/rfc8707)\n    * [x] [RFC9470 - OAuth 2.0 Step Up Authentication Challenge Protocol](https://tools.ietf.org/html/rfc9470)\n    * [x] [(DRAFT) OAuth 2.0 Protected Resource Metadata](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-resource-metadata-03.html)\n  * Client\n    * [ ] [RFC7591 - OAuth 2.0 Dynamic Client Registration](https://tools.ietf.org/html/rfc7591)\n    * [ ] [RFC7592 - OAuth 2.0 Dynamic Client Registration Management Protocol](https://tools.ietf.org/html/rfc7592)\n    * [ ] [OAuth 2.0 Client ID Scheme](https://datatracker.ietf.org/doc/html/draft-looker-oauth-client-id-scheme)\n  * Tokens\n    * Privacy\n      * [x] [Pairwise subject identifier](https://openid.net/specs/openid-connect-core-1_0.html#PairwiseAlg)\n    * Scheme\n      * [x] [RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage](https://tools.ietf.org/html/rfc6750)\n      * [x] [RFC7800 - Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)](https://datatracker.ietf.org/doc/html/rfc7800) \n      * [x] [RFC9449 - OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)](https://datatracker.ietf.org/doc/html/rfc9449)\n      * [ ] [RFC8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens](https://tools.ietf.org/html/rfc8705)\n    * Authentication by reference\n      * [x] Random string\n      * [x] Verifiable token (signed UUID)\n    * Authentication by value\n      * [x] [RFC7519 - JSON Web Token (JWT)](https://tools.ietf.org/html/rfc7519)\n      * [x] PASETO - [draft-paragon-paseto-rfc-00](https://paseto.io/)\n      * [x] [RFC8392 - CBOR Web Token (CWT)](https://tools.ietf.org/html/rfc8392)\n  * Token Management\n    * [x] [RFC7662 - OAuth 2.0 Token Introspection](https://tools.ietf.org/html/rfc7662)\n    * [x] [RFC7009 - OAuth 2.0 Token Revocation](https://tools.ietf.org/html/rfc7009)\n    * [x] (DRAFT) - JWT Response for OAuth Token Introspection - [draft-ietf-oauth-jwt-introspection-response](https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-12)\n\n### Integrations\n\n* HTTP\n  * Authorization Server\n    * [ ] Standalone\n    * [ ] Caddy plugin\n  * Reverse Proxy\n    * [ ] Caddy plugin\n* CoAP\n  * Authorization Server\n    * [ ] Standalone\n* AWS\n  * Auhtorization Server\n    * [x] AWS Lambda\n\n## References\n\n* [OAuth 2.0](https://oauth.net/2/)\n* [OAuth 2.0 Client Authentication](https://medium.com/@darutk/oauth-2-0-client-authentication-4b5f929305d4)\n* [OAuth 2.0 Security Best Current Practice](https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15)\n* [Why you should stop using the OAuth implicit grant!](https://medium.com/@torsten_lodderstedt/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926)\n* [OAuth 2.0 for Browser-Based Apps](https://tools.ietf.org/id/draft-parecki-oauth-browser-based-apps-02.html)\n* [Financial-grade API - Part 1: Read-Only API Security Profile](https://openid.net/specs/openid-financial-api-part-1.html)\n* [Financial-grade API - Part 2: Read and Write API Security Profile](https://openid.net/specs/openid-financial-api-part-2.html)\n* [PKCE vs. Nonce: Equivalent or Not?](https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/)\n* [An Extensive Formal Security Analysis of the OpenID Financial-grade API](https://arxiv.org/abs/1901.11520)\n* [Mix-Up, Revisited](https://danielfett.de/2020/05/04/mix-up-revisited/)\n* [Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)](https://openid.net/specs/openid-financial-api-jarm-ID1.html)\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fzntrio%2Fsolid","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fzntrio%2Fsolid","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fzntrio%2Fsolid/lists"}