'\n```\n\nRequest body from the above, formatted for readability with line wraps:\n\n```\nredirect_uri=\n    &grant_type=authorization_code\n    &client_id=\n    &code=\n```\n\n**Client ID with secret:**\n\n```\ncurl --request POST \\\n  --url :///api/v1/token \\\n  --header 'Authorization: Basic ' \\\n  --header 'content-type: application/x-www-form-urlencoded' \\\n  --data 'redirect_uri=&grant_type=authorization_code&code='\n```\n\nRequest body from the above, formatted for readability with line wraps:\n\n```\nredirect_uri=\n    &grant_type=authorization_code\n    &code=\n```\n\n(You can import cURL commands as new requests in [Postman](https://learning.postman.com/docs/getting-started/importing-and-exporting/importing-curl-commands/) and [Bruno](https://docs.usebruno.com/get-started/bruno-basics/create-a-request).)\n\nThe request body will need to be percent-encoded (which your client library might do for you automatically).\n\nA successful response will include the access token, the ID token, and some other fields. Below is an example. The values in your response may be different:\n\n```JSON\n{\n    \"access_token\": \"H2LkTDZvIImckQQrAkOSeF8z0366OQQk4gHnNsUwNEg2In89viMnAy00YZ7SaZnEVxnTc=\",\n    \"token_type\": \"Bearer\",\n    \"expires_in\": 14400,\n    \"refresh_token\": \"PFTxHHlZEi8ZiorEnI/Q+GPe035n4+B4979dAGucf3GC/I3efSk/W/T/z+cjo82GY6Znw=\",\n    \"id_token\": \"eyJhbGciOiJIUzI1NiJ9.eyJpYXQiOjE3MzgyNjY3MDIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6MzAwMCIsImF1ZCI6InJlbHlpbmdfcGFydHkiLCJzdWIiOiJ0dXNlciIsImV4cCI6MTczODI4MTEwMn0.n1424ax1Jpjxw-kIqPXVUWNz1pVywaIlCXMMoh18rkc\"\n}\n```\n\n### Using the access token to request user info\n\nOnce your backend has the access token, it can use it to learn more about the user via the `/userInfo` endpoint. Do this by sending a GET request in the following format:\n\n```\ncurl --request GET \\\n  --url http://localhost:3000/api/v1/userInfo \\\n  --header 'Authorization: Bearer '\n```\n\n(Note that this request's Authorization header must use the word \"Bearer\" instead of \"Basic\".)\n\nThe endpoint will return a JSON having attributes describing the user. Which attributes you see will depend on the scopes you used when navigating to `/authorize`. The scopes Dev SSO IdP recognizes are:\n\n-   `openid` (Required)\n-   `profile`\n-   `email`\n-   `address`\n-   `phone`\n\n## Setting Dev SSO IdP to automatically redirect\n\nClicking the button to redirect every time is unnecessary, especially if you always want Dev SSO IdP to do the same thing. To have it redirect automatically:\n\n1. Go to Dev SSO IdP's `/settings` or `/authorize` page.\n2. If in the `/authorize` page, click on \"Advanced Settings\", below the red and blue buttons.\n3. Click the checkbox next to \"Auto-redirect after load\".\n\nChanges made to this or other settings in-browser are scoped only to that browser. So, when you set it to auto-redirect (or to not auto-redirect), you don't have to worry about this affecting other users.\n\nIf you've set Dev SSO IdP to auto-redirect and want to turn off this behavior or change more settings, you can do so by going to its settings page. This will be at the `/settings` path, which by default would be [http://localhost:3000/settings](http://localhost:3000/settings).\n\nYou can also control this behavior through a request parameter in the URL. `auto_redirect=y` will have it auto-redirect, while `auto_redirect=n` will disable the redirect regardless of setting.\n\n## `/authorize` request parameters\n\nThe `/authorize` page accepts the following request parameters:\n\n-   **`response_type`:** **(Required)** Must be `code`.\n-   **`scope`:** **(Required)** A string with keywords separated by spaces. When percent-encoded, these spaces become `%20`. For example, a percent-encoded value for this parameter may be `openid%20profile%20email`. Recognized values are:\n    -   `openid` (Required)\n    -   `profile`\n    -   `email`\n    -   `address`\n    -   `phone`\n-   **`client_id`:** **(Required)** Must exactly match a client ID configured in the environment variables.\n-   **`redirect_uri`:** **(Required)** Must exactly match a redirect URL configured in the environment variables.\n-   **`state`:** (Optional) A string of text that is not used by Dev SSO IdP, but is instead returned as-is to your application when Dev SSO IdP redirects back to it. Your application may have various uses for this, such as in mitigating cross-site request forgery.\n-   **`nonce`:** (Optional) A string of text that Dev SSO IdP will return as-is in the `nonce` field of the ID token. This can be used as a security measure to ensure that the request for this ID token came from your app, and specifically from the `/authorize` request associated with this nonce.\n-   **`auto_redirect`:** (Optional) Value should be either `y` or `n` if this parameter is used.\n    -   If `y`, Dev SSO IdP will automatically redirect back to your app.\n    -   If `n`, it will never automatically redirect regardless of any other setting, and the redirect will instead be done as normal by clicking on one of the buttons.\n-   **`loading_delay`:** (Optional) Contains a number of milliseconds. If present and > 0, this parameter will introduce an artificial delay into the loading of Dev SSO IdP's `/authorize` page. The purpose of this is to mimic load times of full-fledged production SSO pages so that, when using Dev SSO IdP for demonstration purposes, others' expectations can be managed with regard to what they'll be seeing in production.\n\n## Customizing `/authorize`, `/token`, and `/userInfo` paths\n\nAs described in the quick start guide, the only environment variables you must provide values for are related to redirect URIs and client IDs. But there are some others that can provide a lot of value through customization.\n\nOf note are the ones that let you change the `/authorize`, `/token`, and `/userInfo` paths. You can change them to be whatever are the corresponding paths used by your production OIDC provider, so that your application's code doesn't need to know how to use different paths based on its environment.\n\n-   **`DEVSSOIDP_AUTHORIZE_PAGE_PATH`:** The path at which this server will expose the authorize page. Defaults to `/authorize`\n-   **`DEVSSOIDP_TOKEN_ENDPOINT_PATH`:** The path at which the server exposes the token endpoint. Defaults to `/api/v1/token`\n-   **`DEVSSOIDP_USER_INFO_ENDPOINT_PATH`:** The path at which the server exposes the user info endpoint. Defaults to `/api/v1/userInfo`\n\nFor complete info on all Dev SSO IdP's environment variables, see the below section, \"Environment variable reference\".\n\n## Providing a TLS certificate\n\nYou may choose to use HTTP instead of HTTPS when making requests to this project's server. But keep in mind that production OpenID providers will always require the use of HTTPS.\n\nIf you want to deploy this project with a TLS certificate:\n\n-   Add your certificate file into a volume, which goes in the container's `/app/ssl/cert` folder.\n-   Add your certificate's private key into another volume, which goes in the container's `/app/ssl/key` folder.\n-   If you need to provide any intermediate certificates, add them into a volume in the container's `/app/ssl/ca` folder. If not, then you don't need to do anything for this.\n-   When starting the container after the above additions, make sure to set the `DEVSSOIDP_USE_HTTPS` environment variable to 'true'.\n\nEvery file in the `ssl/cert` and `ssl/ca` folders must be a certificate, and every file in the `ssl/key` folder must be a private key. (Except for `.gitignore` and, potentially, `.DS_Store`, both of which it ignores.)\n\n## Client authentication with the token endpoint\n\nThe authentication that occurs in the browser is the authentication of the _user_. When the code is exchanged for token, the OIDC provider then authenticates the _client_ (that is, your application). This project provides 3 options for client authentication, which you should choose based on which is closest to what will be used in your production environment:\n\n### Option 1: No authentication\n\nThis is what it will be if the `DEVSSOIDP_CLIENT_IDS_WITH_SECRETS` environment variable is not used (and so the `DEVSSOIDP_CLIENT_IDS` environment variable is used instead). Unless the `DEVSSOIDP_CLIENT_ID_OPTIONAL_FOR_TOKEN_ENDPOINT` environment variable is set to true, the `client_id` will still need to be provided, and must match the client ID used when getting the code.\n\n### Option 2: Basic auth, with secrets stored in `DEVSSOIDP_CLIENT_IDS_WITH_SECRETS` env variable as plain text\n\n**This method is to be used only in sandbox environments having no sensitive data, and for which your secrets do not correspond to any secret used in production.**\n\nThis method uses Basic Authentication for the token endpoint. It requires that each client ID be paired with a secret, and so it uses client IDs from the `DEVSSOIDP_CLIENT_IDS_WITH_SECRETS` environment variable instead. Note that if `DEVSSOIDP_CLIENT_IDS_WITH_SECRETS` contains any values, then the `DEVSSOIDP_CLIENT_IDS` environment variable will be ignored.\n\n`DEVSSOIDP_CLIENT_IDS_WITH_SECRETS` contains a comma-delimited list of client ID/secret pairs. These pairs are themselves delimited by a colon.\n\n-   For example, if you have only one client ID, \"relying_party\", for which the secret is \"mysecret1234\", then the value of this environment variable should be `relying_party:mysecret1234`.\n-   If you have multiple client IDs, then they should each be concatenated with their secrets in this manner, and separated from each other by a comma. For example: `relying_party:mysecret1234,other_client:othersecret1234`\n-   Since the secret is stored in the environment variable in plain text, this method is to be used only in sandbox environments having no sensitive data, and for which your secrets do not correspond to any secret used in production.\n\nWhen making a request to the token endpoint, in accordance with standard Basic Auth practice, the \"Authorization\" header will be needed. The value of this header should be constructed as follows:\n\n1. The client ID and secret should be concatenated with each other, with a colon in between. For example, `relying_party:mysecret1234`.\n2. This text should then be base64-encoded. For the above example, it would result in the following string: `cmVseWluZ19wYXJ0eTpteXNlY3JldDEyMzQ=`\n3. The header value should be the word \"Basic\", followed by a space, and then the generated base64 string. For example, `Basic cmVseWluZ19wYXJ0eTpteXNlY3JldDEyMzQ=`.\n4. And so the complete header when entered into `curl` or any other tool for sending HTTP requests would be `Authorization: Basic cmVseWluZ19wYXJ0eTpteXNlY3JldDEyMzQ=`\n\n### Option 3: Basic auth, with `DEVSSOIDP_CLIENT_IDS_WITH_SECRETS` containing hashes instead of plain text secrets\n\nThis method will be used if the `DEVSSOIDP_HASH_SECRET` environment variable is set to `true`, and `DEVSSOIDP_CLIENT_IDS_WITH_SECRETS` contains any values. This method also requires the `DEVSSOIDP_SALTS_FOR_HASHING_SECRET` environment variable to contain a value.\n\nThis method is the same as the previous in terms of how the request is sent to the token endpoint. The difference is entirely in how the secret is specified in the `DEVSSOIDP_CLIENT_IDS_WITH_SECRETS` environment variable. Instead of the secret, each client ID is instead paired with a SHA-256 hash created from the secret.\n\n-   For example, if the desired client ID is \"relying_party\" and the desired secret is \"mysecret1234\", you will put the secret through a hashing process before setting it in the environment variable.\n-   You should take \"mysecret1234\" and concatenate it with an arbitrary string of your choosing, called the salt. For this example, suppose you choose \"my-super-cool-salt\" as your salt. So, after concatenating, you will have the string \"mysecret1234my-super-cool-salt\".\n-   Input this string into the SHA-256 hashing function, and then base64-encode the output of that. In this example, the result is `dtP556jiLe8bOmBrlnj/L+VLUrVXHH2Dv5DgjhiAxlI=`.\n-   When setting the value of the `DEVSSOIDP_CLIENT_IDS_WITH_SECRETS` environment variable, use this value in place of the secret. So, your value for `DEVSSOIDP_CLIENT_IDS_WITH_SECRETS` would be `relying_party:dtP556jiLe8bOmBrlnj/L+VLUrVXHH2Dv5DgjhiAxlI=`.\n-   Set the `DEVSSOIDP_SALTS_FOR_HASHING_SECRET` environment variable to include the salt that you used. So in this example, the value of that variable would be `my-super-cool-salt`.\n-   Make sure you're also setting `DEVSSOIDP_HASH_SECRET` to `true` if you want to use this method.\n-   Repeat the above for each client ID you wish to use.\n    -   Include all client ID/hash pairs in `DEVSSOIDP_CLIENT_IDS_WITH_SECRETS`, separated by commas.\n    -   Use a different salt for each secret, and include each salt in `DEVSSOIDP_SALTS_FOR_HASHING_SECRET`, again separated by commas. The first salt in this environment variable should correspond to the first client ID/hash pair in `DEVSSOIDP_CLIENT_IDS_WITH_SECRETS`, and so on.\n\nNote that you only need to hash the secret for purpose of populating the `DEVSSOIDP_CLIENT_IDS_WITH_SECRETS` environment variable. The token endpoint request's Authorization header should be constructed as mentioned in the previous method, using the unhashed secret. When the endpoint is validating the Authorization header, it will hash the provided secret and check it against the hash provided in the environment variable, and denying authorization if they don't match. In this way, Basic Auth may be used without the secret being stored.\n\n## Degree of similitude with OpenID Connect providers\n\nThe OpenID Connect specification enumerates both optional features and multiple nonstandard ways in which a mandatory feature may be implemented. This project targets a broad range of implementations to accomodate, but there are too vast a number of potential discrepancies for it to account for all of them.\n\nOne example: the specification notes that the `token_type` field in the token endpoint response must be \"Bearer\", but is case insensitive. This project uses the common init-capped \"Bearer\", but your production OpenID provider may use \"BEARER\". If for some reason your client requires the init-capped string, it will work with this project's server, but not with that of your production environment.\n\nThis project's goal is that it can be used by your lower environment applications as a form-fitting substitute for a normative OpenID provider, but it is still up to you as a developer to do due dilligence in making sure compatibility will be maintained in production.\n\n## Health check endpoints\n\nThis server exposes two endpoints that can be used with automated health checks:\n\n-   **/api/v1/health:** This endpoint indicates basic readiness to serve requests.\n-   **/api/v1/health/env:** Unlike the above endpoint, this one fails if there are any problems detected in any environment variables.\n\nIt is recommended that the first endpoint be used on recurring status checks, and the second on initial checks on server startup. But if you use a Kubernetes deployment that will stop the server if a health check fails, you may wish to use the first endpoint for all checks, so that the server will remain running, and you may see from a UI page what the environment variable problems are. In any event, the server will log to the console any environment variable problems it encounters during validation.\n\n## Running on Kubernetes\n\nThis project's github repository includes [a sample YAML file](https://github.com/bencase/dev-sso-idp/blob/main/sample/k8s-deployment.yaml) with which you can put Dev SSO IdP on a Kubernetes cluster. Deploy it with `kubectl apply -f path/to/k8s-deployment.yaml`\n\nDev SSO IdP works just fine when configuring the cluster to have multiple replicas of its pod, since it is stateless, and so the code from authorize requests to one pod can be handled by token requests to another.\n\n## Using refresh tokens to get new ID and access tokens\n\nBy default Dev SSO IdP will also provide a refresh token alongside ID and access tokens, in the `refresh_token` field. Below shows an example of a request in which this is used to get new tokens after the ID token expired:\n\n```\ncurl --request POST \\\n  --url http://localhost:3000/api/v1/token \\\n  --header 'Authorization: Basic cmVseWluZ19wYXJ0eTpteXN1cGVyc2VjcmV0cHc=' \\\n  --header 'content-type: application/x-www-form-urlencoded' \\\n  --data 'grant_type=refresh_token&refresh_token=df0FXXw1e2+WGx6Y/EeitOb81bwMllU+RxU9qTb8RJdw/0jmdtBndhyU2f0J15HIv94qs=&scope=openid profile'\n```\n\nNote that the value of `grant_type` is `refresh_token`, and there's a new `refresh_token` field.\n\n## Environment variable reference\n\nThis overview is running up against Docker Hub's character limit, so see [the environment variable reference on GitHub](https://github.com/bencase/dev-sso-idp?tab=readme-ov-file#environment-variable-reference).\n\n## Basic troubleshooting\n\nIn case of errors, endpoints will return a message explaining the error, or Dev SSO IdP's UI will provide details. The exception to this is status 403 responses for requests whose access is denied, in which case more info on the error will be available in the server's prints to the console.\n","has_starred","hub_user","immutable_tags_settings",{"_85":11,"_86":87},"enabled","rules",[88],".*","is_automated","permissions",{"_92":21,"_93":11,"_94":11},"read","write","admin","user","storage_size",113637499,"orgData","recentTags",[101,140],{"_102":55,"_103":104,"_105":106,"_107":108,"_109":110,"_111":112,"_61":129,"_130":104,"_131":33,"_132":67,"_43":133,"_134":135,"_136":119,"_137":129,"_138":75,"_139":21},"content_type","creator",7959501,"digest","sha256:0d60071d184d071aa72876302ba74d8f42e84561f896c8f41d4dbf889c96499c","full_size",83890136,"id",844505101,"images",[113],{"_114":115,"_105":106,"_116":117,"_118":119,"_120":121,"_122":123,"_124":117,"_125":-5,"_126":108,"_73":75,"_127":128},"architecture","arm64","features","","last_pulled","2026-09-26T03:37:21.349660784Z","last_pushed","2025-02-13T19:57:38.069811555Z","os","linux","os_features","os_version","size","variant","v8","2025-02-13T20:03:48.582456Z","last_updater","last_updater_username","media_type","latest","repository",26402657,"tag_last_pulled","tag_last_pushed","tag_status","v2",{"_102":55,"_103":104,"_105":106,"_107":108,"_109":141,"_111":142,"_61":144,"_130":104,"_131":33,"_132":67,"_43":145,"_134":135,"_136":119,"_137":144,"_138":75,"_139":21},844464333,[143],{"_114":115,"_105":106,"_116":117,"_118":119,"_120":121,"_122":123,"_124":117,"_125":-5,"_126":108,"_73":75,"_127":128},"2025-02-13T19:57:38.584753Z","1.0.0","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","showSbxLogoOverride","sbxTrademarkText","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"selectedTag","attestationsUrl","routes/_layout.r.$namespace.$reponame.tags",{"_38":159,"_169":170,"_153":183,"_184":11},{"_40":160,"_53":164,"_56":57,"_58":59,"_60":11,"_61":62,"_63":64,"_65":165,"_43":35,"_32":33,"_68":69,"_70":55,"_71":72,"_73":72,"_74":75,"_76":-5,"_77":78,"_79":80,"_81":11,"_82":33,"_83":166,"_89":11,"_90":168,"_95":33,"_96":97},[161,162,163],{"_43":44,"_45":46},{"_43":48,"_45":49},{"_43":51,"_45":52},[55],[67],{"_85":11,"_86":167},[88],{"_92":21,"_93":11,"_94":11},"tags",{"_171":172,"_173":-5,"_174":-5,"_175":176},"count",2,"next","previous","results",[177,180],{"_102":55,"_103":104,"_105":106,"_107":108,"_109":110,"_111":178,"_61":129,"_130":104,"_131":33,"_132":67,"_43":133,"_134":135,"_136":119,"_137":129,"_138":75,"_139":21},[179],{"_114":115,"_105":106,"_116":117,"_118":119,"_120":121,"_122":123,"_124":117,"_125":-5,"_126":108,"_73":75,"_127":128},{"_102":55,"_103":104,"_105":106,"_107":108,"_109":141,"_111":181,"_61":144,"_130":104,"_131":33,"_132":67,"_43":145,"_134":135,"_136":119,"_137":144,"_138":75,"_139":21},[182],{"_114":115,"_105":106,"_116":117,"_118":119,"_120":121,"_122":123,"_124":117,"_125":-5,"_126":108,"_73":75,"_127":128},[],"canDeleteTags","actionData","errors"]
bmcase/devssoidp

Tags for bmcase/devssoidp
