openid connect (authorization code flow) with red hat sso · previous post, but let’s review the...

OpenID Connect (Authorization Code Flow)with Red Hat SSO

[email protected] 2© 2018 LEVVEL.IO ALL RIGHTS RESERVED

In this document, we are going to cover how to configure Red Hat SSO v7.1 for OpenID Connect (OIDC) with the Authorization CodeAuthentication Flow and demonstrate usage with a simple test application. Later, we are going to use this configuration as thebasis for more sophisticated examples using 3Scale API Management.

OpenID Connect (and OAuth2) has emerged as the de factostandard for API, mobile applications, and modern Single PageApplication (SPA) authentication and single sign-on, but it isflexible enough to be used in many other contexts. A typical usecase for OIDC would be a SPA or mobile application that needs toauthenticate an end user and then make API calls that alsorequire authentication.

I’ve covered the details of the OIDC spec (and related specs) in aprevious post, but let’s review the basic idea. From openid.net,“OpenID Connect 1.0 is a simple identity layer on top of theOAuth 2.0 protocol. It allows clients to verify the identity of theEnd-User based on the authentication performed by anAuthorization Server, as well as to obtain basic profileinformation about the End-User in an interoperable andREST-like manner.” This “REST-like manner” makes OIDC morelike an API (in line with OAuth2) than the previous generations ofOpenID. OIDC extends the OAuth2 Authorization Code Grant(three-legged OAuth).

OIDC builds on the lessons of the early OpenID protocols andSAML2 including:

OpenID Connect (Authorization Code Flow) with Red Hat SSO

OIDC can integrate with:

• Traditional web apps

• Mobile apps

• Single Page Applications (SPA)

• Server applications

• Most other actors

Configuration and demonstration with a test applicationAUTHORRobert C. Broeckelmann, Jr. •

Principal Consultant

Introduction

• Keep things simple• Build on top of OAuth2• Use easy-to-consume tokens (JWT)

https://medium.com/@robert.broeckelmann/authentication-vs-federation-vs-sso-9586b06b1380

https://medium.com/@robert.broeckelmann/understanding-openid-connect-series-37c93d25e92b

https://openid.net/connect/

https://medium.com/@robert.broeckelmann/saml2-vs-jwt-understanding-oauth2-4abde9e7ec8b

[email protected] © 2018 LEVVEL.IO ALL RIGHTS RESERVED 3

Each of these application types have a corresponding authentication flow in the OIDC spec that is meant to be used. There is some overlap; as always, there is some gray area (checkout this blog post regarding which OAuth2 Implicit Grantshould be used). Not every vendor uses the same authentication flows to satisfy each use case. At the end of the day, you have to work within the boundaries set by your Identity Provider vendor.

Let’s start with some assumptions to make sure we are all on the same page:

• This document assumes basic familiarity with Red Hat SSO.

• Your deployment of Red Hat SSO v7.1 will conform to the published

supported configurations available here.

• A Self-signed certificate is used for digital signatures on JWT tokens.

• A local user is created for testing. An LDAP, database, or federation

relationship with another IdP could also be used, but these are more

advanced use cases with caveats that are outside the scope of this

document.• We are simulating end user authentication and authorization of a typical web

application with a server side component that is using the OIDC

Authorization Code Authentication Flow with a confidential client.

• So, we are configuring OIDC Authorization Code Authentication Flow (with a

confidential client, i.e., has a client secret). Note, that the OAuth2

Authorization Code Grant is a subset of the OIDC Authorization Code Flow,

so this document serves as an example of both.

• We will use the OIDC test client available here to test the setup when we are

done.

• There will be no OAuth2 consent phase in this example.

• The test application will not use the access token to access an external

resource in this example.

• Ideally, a supported Red Hat SSO Client Adapter would be used to interact

with Red Hat SSO). However, only Java, Javascript, and node.js adapters

are officially supported. For other platforms, a KeyCloak client (which is not

officially supported) plugin appropriate for your platform would be used for

all interaction with the IdP (Red Hat SSO) in the real case (see here). The

Red Hat SSO documentation describes how to configure third-party OIDC

https://medium.com/@robert.broeckelmann/when-to-use-which-oauth2-grants-and-oidc-flows-ec6a5c00d864

https://access.redhat.com/articles/2342861#Comp_7_1

https://github.com/rcbjLevvel/oauth2-oidc-debugger

https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.1/html/securing_applications_and_services_guide/

http://www.keycloak.org/docs/3.0/securing_apps/topics/overview/supported-platforms.html


client libraries.

• Red Hat SSO is going to serve the authentication workflow (i.e., an interactive

login).• For this example, the default Red Hat SSO login screen is used (this can be

customized, if needed).

Red Hat SSO Instance InstallationFollow the instructions here to install Red Hat SSO v7.1. The installation details are outside the scope of this document.

Red Hat SSO Realm Setup Procedure• Go to RH SSO at https://host:8443/auth/admin (replace host with the name of your RH SSO installation).

• Enter a username and password with admin privileges.

https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.1/html/server_installation_and_configuration_guide/

https://host:8443/auth/admin


• Mouse over the “Select realm” drop down.• Click the blue “Add realm” button.

• Add the name “blog_demo”.• Click the “Create” button.

• Make note of the OIDC endpoints by clicking on the OpenID Connect Endpoint configuration link in the Endpoints field. We’ll need several of these values later. For the blog_demo realm, we have:


{

“issuer”: “https://idp.levvel.io:8443/auth/realms/blog_demo”,

“authorization_endpoint”: “https://idp.levvel.io:8443/auth/realms/blog_demo/protocol/openid- connect/auth”,

“token_endpoint”: “https://idp.levvel.io:8443/auth/realms/blog_demo/protocol/openi d-connect/token”,

“token_introspection_endpoint”: “https://idp.levvel.io:8443/auth/realms/blog_demo/protocol/openid- connect/token/introspect”,

“userinfo_endpoint”: “https://idp.levvel.io:8443/auth/realms/blog_demo/protocol/openid- connect/userinfo”,

“end_session_endpoint”: “https://idp.levvel.io:8443/auth/realms/blog_demo/protocol/openid- connect/logout”,

“jwks_uri”: “https://idp.levvel.io:8443/auth/realms/blog_demo/protocol/openid- connect/certs”,

“check_session_iframe”: “https://idp.levvel.io:8443/auth/realms/blog_demo/protocol/openid- connect/login-status-iframe.html”,

“grant_types_supported”: [ “authorization_code”, “implicit”, “refresh_token”, “password”, “client_credentials” ],


“response_types_supported”: [ “code”, “none”, “id_token”, “token”, “id_token token”, “code id_token”, “code token”, “code id_token token” ],

“subject_types_supported”: [ “public”, “pairwise” ],

“id_token_signing_alg_values_supported”: [ “RS256” ],

“userinfo_signing_alg_values_supported”: [ “RS256” ],

“request_object_signing_alg_values_supported”: [ “none”, “RS256” ],

“response_modes_supported”: [ “query”, “fragment”, “form_post” ],

“registration_endpoint”: “https://idp.levvel.io:8443/auth/realms/blog_demo/clients- registrations/openid-connect”,


“token_endpoint_auth_methods_supported”: [ “private_key_jwt”, “client_secret_basic”, “client_secret_post” ],

“token_endpoint_auth_signing_alg_values_supported”: [ “RS256” ],

“claims_supported”: [ “sub”, “iss”, “auth_time”, “name”, “given_name”, “family_name”, “preferred_username”, “email” ],

“claim_types_supported”: [ “normal” ],

“claims_parameter_supported”: false,

“scopes_supported”: [ “openid”, “offline_access” ],

“request_parameter_supported”: true,

“request_uri_parameter_supported”: true

}

• Click on the Keys tab.


• Click the Providers tab.

• Click the drop down.• Choose “rsa-generated”.

• Change the “Console Display Name” to “blog-post-rsa-key-pair”.• Set priority to 100.• Click the Save button.• Click the Providers tab.


• Click the Delete link next to the rsa-generated key pair.

• Click the Delete button.

• Note, if your organization has a key pair (with certificate issued out of an internal CA) that should be used for signing tokens, then that be uploaded using a similar set of steps.• Click on the Tokens tab.


• Change the Access Token Lifespan to 60 minutes. The actual value used for a production application will depend on several factors. We are using 60 minutes here so that things do not timeout while completing the tutorial.• Change the Client login Timeout to 5 minutes. Once again, the default value of one minute is recommended; we are changing the value to five minutes so there is sufficient time to complete the steps in this tutorial.

Setup Red Hat SSO Client Configuration

• Click the Clients link in the left-hand column.

• Click the Create button.


• Set the Client ID to “blog-post-demo-client-001”.• Set the Client Protocol to “openid-connect” (the default).• Click the Save button.


• Set Consent Required to Off. We are not going to deal with user consent in this simple example — that will come later.• Set Access Type to Confidential.• Set Standard Flow Enabled to On.• Set Implicit Flow Enabled to On.• Set Direct Access Grants enabled to On.• Set Service Accounts Enabled to On.• Set Valid Redirect URLs to “http://localhost:3000/callback”.• Click the Save button.


• Scroll down to the Web Origins field at the bottom of the Settings tab.• Enter “http://localhost:3000/*”. If the base URL of the test client will be different, then use that URL here. Although, not recommended, “*” can be used.• Click Save.


• Click the Credentials tab.

• Make note of the Secret value (this is the client secret).• Click on the Roles tab.


• Click the “Add Role” button.

Create The Test User

• Put “User” in the Role Name.• Put “The User role.” in the Description field.• Set “Scope Param Required” to Off. As long as the user is a member of a group that is mapped to the User role, the access token will show membership in this role.• Click the Save button.


• Click on the Users link on the left-hand column.

• Click the “Add user” button.


• Add user1 to the Username field.• Click the Save button.


• Click on the Credentials tab.

• Add a password for this user to the “New Password” field (maybe, “password123”).


• Reenter the same password into the “Password Confirmation” field.• Set Temporary to Off.• Click the red Reset Password button.

• Click “Change Password”

Create The Test Group

• Click on the Groups link on the left-hand column.

• Click the New button.

• Enter Group1 in the name field.• Click Save


• Click the Role Mappings tab.

• In the Client Roles drop down, choose “blog-post-demo-client-001”

• Select the User role from the “Available Roles” field.


• Click “Add selected”

• Click on the Members tab.

• Go back to the users section.

• Click on the link for the user1 user.


• Click on the Groups tab.

• Select Group1 from the Available Groups list.• Click the Join button.


• If you are following these instructions for another blog post, you can stop here.• Follow the instructions here to setup the OAuth2 + OIDC Debugger app on your local machine. This is a simple test application that simulates the interaction between a real app and an IdP using the OAuth2 or OIDC protocols.• Open a browser tab and go to http://localhost:3000

https://github.com/rcbjLevvel/oauth2-oidc-debugger


• Choose “OIDC Authorization Code Flow.”• The screen will refresh. It will look very similar to the OAutho2 Authorization Code Grant option above.


• Populate the Authorization Endpoint field with the URL from the meta data document we captured earlier (authorization_endpoint attribute).• Populate the Token Endpoint field with the URL from the meta data document we captured earlier (tokend_endpoint attribute).• Put the client identifier in the Client Id field (use “blog-post-demo-client-001”).• The default Redirect URL should work for this example (http://localhost:3000/ callback).• Put “openid profile User” in the Scope field. The debugger automatically populates this field with “openid profile”.


• For this example, a resource is not needed; so, leave “Add Resource field?” as “No”.• Click the Authorize button.• This will result in the following request being sent to Red Hat SSO:

GET

https://idp.levvel.io/auth/realms/demo_project_sf/protocol/openid-connect/auth?

state=38610846-c64d-4fd2-8d9-b5fa2f976298&

response_type=code&

client_id=blog-post-demo-client-001&

redirect_uri= http://localhost:3000/callback&

scope=openid profile User

• Red Hat SSO will prompt for credentials if there isn’t already an authenticated session.

• Enter the username (User1) in the “Username or email” field.• Enter the password (password123) in the Password field.• Click the “Log in” button.• The IdP validates the credentials and returns an authorization code.


• The callback endpoint refreshes the page and populates the Authorization Code field.

• Put the client identifier in the Client ID field (use “blog-post-demo- client-001”).• Put the client secret in the Client Secret field.• Put “openid profile User” in the scope field.• A resource does not need to be specified in this example. So, leave “No” selected for the “Add Resource field?” question.• If your Red Hat SSO instance is using a self-signed certificate (or non-public CA), then choose “No” for “SSL Certificate Validation?”.• Click the “Get Token” button.• The debugger application sends the following request to the IdP:


POST

https://idp.levvel.io:8443/auth/realms/blog_demo/protocol/openid-connect/token?

grant_type=authorization_code&

code=XGflSf5kFIpAE_VNBcbGqH9D030qOeuU2yw5kiBAPcg.6df35f39-bbc5-4eb3-bf92-79e94644b957&

client_id=blog-post-demo-client-001&

redirect_uri= http://localhost:3000/callback&

scope=openid profile User

• This will return a response with the access token, ID Token, refresh token, and other attributes


• This response from the IdP looks similar to the following (note, the tokens shown below have been corrupted so that you cannot see the original contents):

{“access_token”:“eyJhbGciOiJSUzI1NiIsInR5cCIgOixAiSldUIiwia2lkIiA6ICJlbxng0N0Fq FdVRHhBWjRidkl4RFJGMXBlSnpPNnZpa0JvUW8x5U2MzYVVRIn0.eyJqdGkiOiIyNzk3Yzk3YS1jYTsMzLTQzxMdTMxtYjVlxZC00xNjcx1M4fTIzYzFiOTgiLCJleHAiOxjE1MTAzNjU2MTgsIm5iZiI6MCwxiaWF0IjoxNTEwMzY1MzE4LCJpc3MiOiJodHRwczovL2VjMi01Mi03Mi03MS0yMjkxuY29tcHV0ZS0xLmFtYXpvbmF3cy5jb206xODQ0My9hdXRoL3JlYWxtcy9ibG9nX2RlbW8iLCJhd6WQixOiJibG9nLXBvc3QtZGVtby1jbGllbn0QtMDAxIiwic3ViIjoxiNzFjOTA0ZjEtZTk3O8C00NTQyLTgwZGUtZmE5OGViYjI0MWU1IiwidHlwIjoiQmVhcmVyIxiwiYXpwIjoiYmxvZy1wb3N0LWRlbW8tY2xpZW50LTAwMSIsIm5vbmNlIjoiMWVmODdlZGMtNzZkYy00YWYzLWJmMmYtNWEzNzJjZTA2YmUyIiwiYXV0aF90aW1lIjoxNTEwMzYxMTYxLCJzZXNzaW9uX3N0YXRlIjoiYjY3M2M4M2YtYTY3Mi00M2YxLWFkMWItNjI2OG5E5N2M5MDMwIiwiYWNyIjoiMCIsIm987896NsaWVudF9zZXNzaW9uIjoiNTBmZWM2YWEtMzMyZS00MmU0LWFiM2UtMzE0YTU2NGJjYTBiIiwiYWxsb3dlZC1vcmlnaW5zIjpbIioiLCJodHRwOi8vbG9jYWxob3N0OjMwMDAiXSwicmVzb3VyY2VfYWNjZXNzIjp7ImJsb2ctcG9zdC1kZW1vLWNsaWVudC0wMDEiOnsicm9sZXMiOlsiVXNlciJdfX0sIm5hbWUiOiIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ1c2VyMSJ9.AYvnrPJ615eMNEWcr3zjD0auPgYr6ZsmYw1JR___0sTNW9YL3YyatEUttPAiJZNsr15s93xBp40svbv_GlZgsG57FZaYF0PNH79nbd8EzcrA_-M6vVED1mLQR9rd96Ec8ISCzEQhYcESBmOjI1ZZ2cFP05Uw1AfLI1CXWT9ExTbKknnahIYVLOeFJ2n9xr7JYgolBfeE4VksIktEk0hlUQf762nQ8uwZ4ycGBfHAZkLfvTodyQT5T3ulpNMg0_SSQDGmACKrq9YhG8wshw2PWWTjAMfnARvM5NiPCxGaf3qnFFz5bWjMbbDAyVKRmRYl1S8rJ2q1WBK9HkFH5fHIzng”,

“expires_in”: 300,

“refresh_expires_in”: 1800,

“refresh_token”:

“eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJlbng0N0FqcFdVRHhBWjRidkl4RFJGMXBlSnpPNnZpa0JvUW85U2MzYVVRIn0.eyJqdGkiOiI4MWRjNGQ4NS1hMzdhLTRkZxmEtxOGNxiOC0zMxGE3OxDNiNDIxYzIiLCJleHAiOjE1MTAzNjcxMTxgsImx5ixZiI6MCxwiaWF0xIjoxNTEwMzY1MzE4LCJpc3MiOixJodHRxwczovL2VjxMi01Mix03Mi03MS0yMjkuY29tcHV0ZS0xLmFtYXpxvbmF3cy5jxb206ODQ0My9hdXRoL3JlYWxtcy9ibG9nX2RlbW8iLCJhdWQiOiJibG9xxnLXBvc3QtZGVtby1jbGllbnQtMDAxIiwic3ViIjoiNzFjOTA0ZjEtZTk3OC00NTQyLTgwZGUtZ


mE5OGViYjI0MWU1IiwidHlwIjoiUmVmcmVzaCIsImF6cCI6ImJsb2ctcG9zdC1kZW1vLWNsaWVudC0wMDEiLCJub25jZSI6IjFlZjg3ZWRjLTc2ZGMtNGFmMy1iZjJmLTVhMzcyY2UwNmJlMiIsImF1dGhfdGltZSI6MCwic2Vzc2lvbl9zdGF0ZSI6ImI2NzNjODNmLWE2NzItNDNmMS1hZDFiLTYyNjhhOTdjOTAzMCIsImNsaWVudF9zZXNzaW9uIjoiNTBmZWM2YWEtMzMyZS00MmU0LWFiM2UtMzE0YTU2NGJjYTBiIiwicmVzb3VyY2VfYWNjZXNzIjp7ImJsb2ctcG9zdC1kZW1vLWNsaWVudC0wMDEiOnsicm9sZXMiOlsiVXNlciJdfX19.PlZuB-TY_UasHdW-bEhC-uZQpTtm3-Jdnw5Gh5FIE8q6d3iAyUWyjHLrhL80z71XO8M8oeCW3Zjzd8QCPDbSyPJSiSCcDwgIRV7m0FKQJI-F7kBroYR-ADYi6SULl1Ul8PrOI0repgcLCVeaAkM07uXuIE2popMTbQzP1eZk7zjO0MvjUtBkk7UH-aAGV-75KarU0JQMLnKpu-DAp3A8fPmbgjLTu1eajj7DqAkcwJZWm7CefTzM3Kl5BRt4HiDcEsSbJfSVtPnlwmUoClholzu5-vgf7_5a8O-Alqn_SnRXuXkaaIRSL1ZZVCER-HuTLYWJFtRlXfbIbuiiktgAQg”,

“token_type”: “bearer”,

“id_token”:“eyJhbGciOiJSxUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJlbng0N0FqcFdVRHhBWjRidkl4RFxJGMXBlSnpPNxnZpax0JvUWx85U2MzYVxVRInx0.eyJqdxGkiOiJiZmFlMx2M2OS1xiYzkxLxTQ5Y2IxtODM2Yi0zZxDNmMjJkYjxFhYzxMiLCJlxeHAiOjE1MxTxAzNjU2xMTgsIm5ixZiI6MCwiaxWF0IjoxNTExwMzY1MzEx4LCJpc3MiOiJodHRwczovL2VjMi01Mi03Mi03MS0yMjkuY29tcHV0ZS0xLmFtYXpvbmF3cy5jb206ODQ0My9hdXRoL3JlYWxtcy9ibG9nX2RlbW8iLCJhdWQiOiJibG9nLXBvc3QtZGVtby1jbGllbnQtMDAxIiwic3ViIjoiNzFjOTA0ZjEtZTk3OC00NTQyLTgwZGUtZmE5OGViYjI0MWU1IiwidHlwIjoiSUQiLCJhenAiOiJibG9nLXBvc3QtZGVtby1jbGllbnQtMDAxIiwibm9uY2UiOiIxZWY4N2VkYy03NmRjLTRhZjMtYmYyZi01YTM3MmNlMDZiZTIiLCJhdXRoX3RpbWUiOjE1MTAzNjExNjEsInNlc3Npb25fc3RhdGUiOiJiNjczYzgzZi1hNjcyLTQzZjEtYWQxYi02MjY4YTk3YzkwMzAiLCJhY3IiOiIwIiwibmFtZSI6IiIsInByZWZlcnJlZF91c2VybmFtZSI6InVzZXIxIn0.MnryJ_SXqi0FEZo5cfVEhsg8pLVy1nBrrtxud3bP7XWpINSkY6n6xQycWvOxhEBga2x82RM4qB6mcprgJm3LsBitjrV4X24AJyv1v2sBp1xX0skgKVLyD70UTFRhL9q-koJTu4CMCIich-wmFnhrRnzUujafLVL61LVS41keVfScRdOofDHoAZBXicwhHIi5SM9Poo16EIsHgh31_i9AKsX7gkaZskgx_erJe1ArAmxxVf23LPkYpcQM-4R6aEN_jZ9JQowHZmLbj7zltvbATApTFMQ6SoswhtnA8bVezT3P-PC2didkeSNzTyKYhyUviuN1fASm7T2zj58ZCy-b2Q”,

“not-before-policy”: 0,

“session_state”: “b673c83f-a672-43f1-ad1b-6268a97c9030”

}


• The OAuth2 access token is stored in the access_token attribute. This is a JWT token. The JWT payload contains:

{ “jti”: “2797c97a-ca33-4313-b5ed-4675123c1b98”,

“exp”: 1510365618,

“nbf”: 0,

“iat”: 1510365318,

“iss”: “ https://ipd.levvel.io/auth/realms/blog_demo “,

“aud”: “blog-post-demo-client-001”,

“sub”: “71c904f1-e978-4542-80de-fa98ebb241e5”,

“typ”: “Bearer”,

“azp”: “blog-post-demo-client-001”,

“nonce”: “1ef87edc-76dc-4af3-bf2f-5a372ce06be2”,

“auth_time”: 1510361161,

“session_state”: “b673c83f-a672-43f1-ad1b-6268a97c9030”,

“acr”: “0”,

“client_session”: “50fec6aa-332e-42e4-ab3e-314a564bca0b”,

“allowed-origins”: [ “*”, “ http://localhost:3000 “ ],

“resource_access”: { “blog-post-demo-client-001”: { “roles”: [ “User” ] } },


“name”: “”,

“preferred_username”: “user1”

}

You can see that the JWT token describes a user called “user1” and that it is a member of the User role.

An alternative testing mechanism is to run the following shell script that simulates at the calls made to the IdP for the Authorization Code Flow.

#!/bin/bash

#set -x

STATE=`uuidgen`

CLIENT_ID=MY_CLIENT_ID

CLIENT_SECRET=MY_CLIENT_SECRET

FINAL_REDIRECT_URI= http://localhost:3000/callback

USERNAME_=MY_USERNAME

PASSWORD_=MY_PASSWORD

IDP_BASE_URL=https://idp.levvel.io:8443/auth/realms/blog_demo/pr otocol/openid-connect

CURL_OUTPUT=`curl -X GET“${IDP_BASE_URL}/auth?client_id=${CLIENT_ID}&response_type=code&scope=openid%20profile%20email&state=${STATE}&redirect_uri=${FINAL_REDIRECT_URI}” --insecure -D headers.out`

echo CURL_OUTPUT=${CURL_OUTPUT}

PASSWORD_SUBMIT_URL=`echo $CURL_OUTPUT | awk ‘{print $100 }’ |


cut -c 8- | sed ‘s/\”//g’`

echo PASSWORD_SUBMIT_URL=${PASSWORD_SUBMIT_URL}

CURL_OUTPUT=`curl -X POST “${PASSWORD_SUBMIT_URL}” -d “username=${USERNAME_}&password=${PASSWORD_}” --insecure -D/var/tmp/headers.out`

echo CURL_OUTPUT=$CURL_OUTPUT

echo /var/tmp/headers.out

REDIRECT_URL=`cat /var/tmp/headers.out | grep ^Location | cut-c10-`

echo $REDIRECT_URL

CODE=ècho $REDIRECT_URL | awk -F”?” ‘{ print $2 }’ | awk -F”&”‘{print $2}’ | awk -F”=” ‘{print $2}’ | sed ‘s/\r//g’`

echo CODE=$CODE

CURL_OUTPUT=`curl -X POST “${IDP_BASE_URL}/token” -d“state=${STATE}&code=${CODE}&grant_type=authorization_code&client_id=${CLIENT_ID}&client_secret=${CLIENT_SECRET}&redirect_uri=${FINAL_REDIRECT_URI}” --insecure -D headers.out`

echo CURL_OUTPUT=${CURL_OUTPUT}

ACCESS_TOKEN=ècho ${CURL_OUTPUT} | python -c “import sys, json;print json.load(sys.stdin)[‘access_token’]”`

echo “-------------------------------------”

echo ACCESS_TOKEN=${ACCESS_TOKEN}

echo “-------------------------------------”

ID_TOKEN=ècho ${CURL_OUTPUT} | python -c “import sys, json;print json.load(sys.stdin)[‘id_token’]”`

echo “-------------------------------------”


echo ID_TOKEN=${ID_TOKEN}

echo “-------------------------------------”

REFRESH_TOKEN=`echo ${CURL_OUTPUT} | python -c “import sys,json; print json.load(sys.stdin)[‘refresh_token’]”`

echo “-------------------------------------”

echo REFRESH_TOKEN=${REFRESH_TOKEN}

echo “-------------------------------------”

The output of this script will look something like:

-------------------------------------

ACCESS_TOKEN=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJlbng0N0FqcFdVRHhBWjRidkl4RFJGMXBlSnpPNnZpa0JvUW85U2MzYVVRIn0.eyJxqdGkiOxiIzMzxJlMGY1Zi04NxDgxLTQxZDAxtYTRxmZi02ZxDRiZjgyMxmFkNDcixLCJleHAiOjxE1MTAwMzxM2MjgsImx5iZiI6MCxwiaWF0IjoxNxTEwMDMxzMzI4LCJpc3MiOiJodHRwczovL2VjMi01Mi03Mi03MS0yMjkuY29tcHV0ZS0xLmFtYXpvbmF3cy5jb206ODQ0My9hdXRoL3JlYWxtcy9ibG9nX2RlbW8iLCJhdWQiOiJibG9nLXBvc3QtZGVtby1jbGllbnQtMDAxIiwic3ViIjoiNzFjOTA0ZjEtZTk3OC00NTQyLTgwZGUtZmE5OGViYjI0MWU1IiwidHlwIjoiQmVhcmVyIiwiYXpwIjoiYmxvZy1wb3N0LWRlbW8tY2xpZW50LTAwMSIsImF1dGhfdGltZSI6MTUxMDAzMzMyNywic2Vzc2lvbl9zdGF0ZSI6ImU2MmI1NDIyLTY5YTMtNGFjZC04MDU5LTJjNTIxNWU0NmJlZCIsImFjciI6IjEiLCJjbGllbnRfc2Vzc2lvbiI6IjQyODQzNGUzLTllNzItNGM1Ny05YTQ4LTFlMWMxNmZkNWI2YyIsImFsbG93ZWQtb3JpZ2lucyI6W10sInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJ2aWV3LXByb2ZpbGUiXX19LCJuYW1lIjoiIiwicHJlZmVycmVkX3VzZXJuYW1lIjoidXNlcjEifQ.dfjXZrNOb0oyoI6FoMxPmjiLAfI2orzOD0zeTA29z4C8cSoOifKnkL5clbFP_kk1ejHEnmFn17OIxx1_s5m6lRmLXHq6u6ZhSnjYCqvLwbDfszaiZzcJ_UbJagnJ_QfuIwlEdnRJj9C6Ne-ZEm8WwCLDidyDNyA6LufaKUVyFgPs4A4pYOy28YhU8sIBgOgjkmbR5lFK07Z0Uj3bsPFEJOu51E7VWgbIQQPlQFa95Hmw8BSHVcJRytj3gmBSHlavLh232jR2D0GyHzphmi2hgw4UBdHIx23H2bJUUbD7XXGxPENHazrx5U1xo_ojkJXlS1et158P66mr9wTzMnZULw

-------------------------------------

-------------------------------------


ID_TOKEN=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJlbng0N0FqcFdVRHhBWjRidkl4RFJGMXBlSnpPNnZpa0JvUW85U2MzYVVRIn0.eyJqxdGkixOiIwZGU4MxDc1Mi1hZTxdmLTRkODMtYxjI2Zi02NjxU0YmE4Y2UxwNDQiLCJleHxAiOjE1MTAxwMzM2MxjgsIm5iZiIx6MCwiaWF0IxjoxNTEwMDMxzMzI4LCJpc3xMiOiJodHRwxczovL2VjxMi01Mi03xMi03MS0yMxjkuY29tcHxV0ZS0xLxmxFtYXpvbmF3cy5jb206ODQ0My9hdXRoL3JlYWxtcy9ibG9nX2RlbW8iLCJhdWQiOiJibG9nLXBvc3QtZGVtby1jbGllbnQtMDAxIiwic3ViIjoiNzFjOTA0ZjEtZTk3OC00NTQyLTgwZGUtZmE5OGViYjI0MWU1IiwidHlwIjoiSUQiLCJhenAiOiJibG9nLXBvc3QtZGVtby1jbGllbnQtMDAxIiwiYXV0aF90aW1lIjoxNTEwMDMzMzI3LCJzZXNzaW9uX3N0YXRlIjoiZTYyYjU0MjItNjlhMy00YWNkLTgwNTktMmM1MjE1ZTQ2YmVkIiwiYWNyIjoiMSIsIm5hbWUiOiIiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJ1c2VyMSJ9.NWc9-smsugo74-3cDi_zl9-rEo508vt-IubuFYbPj4I1txwrKEVtuqqLbanQGIFJ5DH1bFfGsegZZV4KBoojTlN5ZHVfM--Van5wKFPFaeElUwE6RFtTQIe7kIIPeCNWtbaqpKc85yojs7vUyGXKJzpV52C8U5-4Dr9w4BrhGkIUgIw3ptblbciT2mwGm4ssyqGlx_6G30dBE-PCLWQYw7bkFVgniJNqS_1f0CLH5_XpHGM34ek71XAbSFeiN1zUEMAe_pHZZ_TJRD6p-fRiWpsJyBSoMSbWCtK6-_h2cymRJ3YvRlXFnyN3UKsRUjOAWs8KO4shoDfM7Ke26n9agw

-------------------------------------

-------------------------------------

REFRESH_TOKEN=eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJlbng0N0FqcFdVRHhBWjRidkl4RFJGMXBlSnpPNnZpa0JvUW85U2MzYVVRIn0.eyJqxdxGkiOixIyOWUzMTYzxZC1kOWM4xLTQ3OWYtODUyxMC01OWVhxOWIzN2VkxM2UiLCJxleHAiOjE1xMTAwMzUxMxjgsIm5iZiIx6MCwiaWF0IxjoxNTEwMDxMzMzI4LCxJpc3MiOxiJodHRxwczovL2VjMix01Mi03Mi03MSx0yMjkuY2x9tcHV0ZS0xxLmFtYXpvxbmF3cy5jb2x06ODQ0My9hxdXRoL3JlYWxxtcy9ibGx9nX2RlbWx8xiLCJhdWQiOiJibG9nLXBvc3QtZGVtby1jbGllbnQtMDAxIiwic3ViIjoiNzFjOTA0ZjEtZTk3OC00NTQyLTgwZGUtZmE5OGViYjI0MWU1IiwidHlwIjoiUmVmcmVzaCIsImF6cCI6ImJsb2ctcG9zdC1kZW1vLWNsaWVudC0wMDEiLCJhdXRoX3RpbWUiOjAsInNlc3Npb25fc3RhdGUiOiJlNjJiNTQyMi02OWEzLTRhY2QtODA1OS0yYzUyMTVlNDZiZWQiLCJjbGllbnRfc2Vzc2lvbiI6IjQyODQzNGUzLTllNzItNGM1Ny05YTQ4LTFlMWMxNmZkNWI2YyIsInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJ1bWFfYXV0aG9yaXphdGlvbiJdfSwicmVzb3VyY2VfYWNjZXNzIjp7ImFjY291bnQiOnsicm9sZXMiOlsibWFuYWdlLWFjY291bnQiLCJ2aWV3LXByb2ZpbGUiXX19fQ.LiiPu5jy5a3Y1wkdtKkm0Pp2D7llHeCpE6cAArbp5dWutqhcaGeVAs0eOgCx-IrfqHwZGY1bYdkTa0a2EB-MH8gJCYMZ3xqVeJ9yNaqBjrlM0bJwLT7pvf8kni1R6fsI3odOCS7S_Cy8Haj80EbQ6Zxmw8h5TGL6ZGiXVJPOzzMmuFLA7S02YPqKf9sXHqDy5lHbkSIUGSxCU2kLNUkxzwCfeN7_vYbX9AH2ygoYm3y2fCjV7er9qLwL5Can3JBCfeqF0a7H-KOP1BYXrBk-eEZp8K5bCx1PChx6OlwVKpE3H3FcZeeRLKOFelGT-GgGdNTSrF3UOIUJbD-gbpjHCw


-------------------------------------```

You can customize this script to work with your IdP and client by updating:

• CLIENT_ID• CLIENT_SECRET• FINAL_REDIRECT_URL• USERNAME_• PASSWORD_

In future posts, we’ll look at the other OAuth2 Grants and OIDC flows that are supported by Red Hat SSO, integration with 3Scale, and explore the RH SSO implementation details of the specs.

https://medium.com/@robert.broeckelmann/red-hat-sso-and-3scale-series-d904f2127702

openid connect (authorization code flow) with red hat sso · previous post, but let’s review the...

Documents