FAS Authorization Server - OpenID Connect Onboarding

Transcription

1 FAS Authorization Server - OpenID Connect Onboarding

2 Table of Contents Table of Contents 1 List of Figures 2 1 FAS as an authorization server 3 2 OpenID Connect Authorization Code Request and Response OPENID CONNECT AUTHORIZATION CODE REQUEST Acr_values Scopes and Claims OPENID CONNECT AUTHORIZATION CODE RESPONSE 7 3 OpenID Connect Access Token request and Response OPENID CONNECT ACCESS TOKEN REQUEST Client Secret Basic OPENID CONNECT ACCESS TOKEN RESPONSE Verifying the access token and the ID token 10 4 OpenID Connect User Info request and Response OPENID CONNECT USER INFO REQUEST OPENID CONNECT USER INFO RESPONSE User Info Response Validation 13 5 Requesting a new access token with a refresh token 14 6 Validating a JWT token CHECKING THE CONTENT OF THE TOKEN CHECKING THE SIGNATURE OF THE TOKEN Obtain the public key Check the signature 17 7 OIDC Logout 18 1

3 List of Figures Figure 1: OpenID Connect flow diagram... 3 Figure 2: Table of parameters for authorize request... 4 Figure 3: Overview of authentication means... 5 Figure 4: Example of authorize request... 7 Figure 5: Example of authorize response... 7 Figure 6: Example of access token request... 8 Figure 7: Example of access token response... 9 Figure 8: Header of decoded ID token... 9 Figure 9: Payload of decoded ID token Figure 10: Signature of the ID token Figure 11: Example of user info request Figure 12: Example User Info Response Figure 13: Decoded header of example user info token Figure 14: Decoded payload of example user info token Figure 15: Signature of example user info token Figure 16: Example of public key builder Figure 17: Example of JWT verifier Figure 18: Example of user endsession request

4 1 FAS as an authorization server Figure 1: OpenID Connect flow diagram 1. The client application sends an Authorization Code Request towards the FAS Authorization server via the browser. 2. User authenticates using one of the authentication methods. 3. FAS authorization server sends an Authorization Code via the browser to the redirect-uri of the client application. 4. The client application exchanges the Authorization Code for an Access token, Refresh token and ID token using server to server communication and OIDC client authentication method client_secret_basic. 5. FAS sends an Access token, Refresh token and ID token via server to server communication to the client application. 6. The client application optionally calls the userinfo endpoint of the FAS using the Access Token. 7. FAS sends a signed JWT with extra user information to the client application. 8. The client application is now able to create a local session for the user. 3

5 2 OpenID Connect Authorization Code Request and Response 2.1 OPENID CONNECT AUTHORIZATION CODE REQUEST The Authorization code request and response MUST NOT be signed. However the state parameter SHALL be used to avoid cross-site request forgery attacks. The state parameter is an unguessable string known only to your application, and check to make sure that the value has not changed between requests and responses. This is clearly stated in the Security considerations section Cross-Site Request Forgery of RFC 6749 (oauth 2.0) and in section 3.6 of RFC6819. The nonce parameter SHALL be used. The authorization code can be obtained by executing a GET request towards the Authorization Code endpoint of the FAS (.../fas/oauth2/authorize) with the following parameters: Parameter scope MUST contain openid response_type MUST be code client_id SHALL be nativeappclientid redirect_uri SHALL include The https scheme state MUST contain An opaque value used to maintain state between the request and the callback response_mode SHALL NOT be used nonce MUST be used A nonce will be used for KPI monitoring reasons display SHALL NOT be used prompt SHALL NOT be used max_age SHALL NOT be used ui_locales SHALL NOT be used id_token_hint SHALL NOT be used acr_values SHALL be used Which LoA will be required by the client (See chapter 2.1.1) claims SHALL NOT be used Figure 2: Table of parameters for authorize request 4

6 2.1.1 Acr_values The list of possible acr_values between a RP and the FAS is given below: urn:be:fedict:iam:fas:level500 urn:be:fedict:iam:fas:level450 urn:be:fedict:iam:fas:level400 urn:be:fedict:iam:fas:level300 urn:be:fedict:iam:fas:level200 urn:be:fedict:iam:fas:level100 Below you find a table, containing an overview of all authentication means offered and supported by FOD BOSA: Authentication level Authentication Means Authentication contract Technical Level 500 eid urn:be:fedict:iam:fas:level500 (Always present) High It s Me urn:be:fedict:iam:fas:level Mobile App SMS OTP (*) urn:be:fedict:iam:fas:level Token urn:be:fedict:iam:fas:level Low Username/Password urn:be:fedict:iam:fas:level Without identification Self-registration without usage of NRN urn:be:fedict:iam:fas:level Figure 3: Overview of authentication means (*) The usage of SMS requires an additional contract between the customer and mobile operator. Please ask for the addendum. 5

7 2.1.2 Scopes and Claims Given below is the list of supported scopes and the claims that they will return in the user info token (see section 4). openid o profile o This scope is a MUST if you want an ID-token (specific scope in OAuth to upgrade your request to an OIDC request) This scope will return the following claims: surname givenname fedid PrefLanguage mail egovnrn o This scope will only return the RRN/NRN or BIS number claim of the authenticated user. certificateinfo o If the user authenticates using eid and the scope certificateinfo is requested FAS will return the following claims (if present in the eid certificate): cert_issuer cert_subject cert_serialnumber cert_cn cert_givenname cert_sn cert_mail citizen o States that the end-user authenticates as a natural person o This scope is currently incompatible with the enterprise and roles scope. o This scope is default if a RP doesn't request the enterprise or citizen scope. enterprise o States that the request is made in the name of an enterprise o (roles and enterprise should be combined) roles o This is an explicit request from roles of the authenticating end-user o (roles and enterprise should be combined) For the citizen, enterprise and roles scopes, the following pairs are allowed: roles + enterprise citizen only Note: citizen is the default scope if a RP doesn't request a citizen or enterprise scope. 6

8 Example of an Authorize Code Request: GET &CLIENT_ID=MYCLIENTID &SCOPE=OPENID%20PROFILE &ACR_VALUES=URN:BE:FEDICT:IAM:FAS:LEVEL500 &REDIRECT_URI= &STATE=AF0IFJSLDKJ &NONCE= Figure 4: Example of authorize request 2.2 OPENID CONNECT AUTHORIZATION CODE RESPONSE The response to the authorize request will be a redirect (GET) to the redirect_uri of the authorization code request with the following parameters: Parameter scope WILL contain The requested scopes code WILL contain The authorization code state WILL contain Must be the same value as in the authorization request client_id WILL contain The client ID iss WILL contain The issuer of the authorization code REDIRECT_URI?CODE= C08E-431A-A5DC-2E B43 &SCOPE=OPENID%20PROFILE &ISS=HTTP%3A%2F%2FIDP.IAMFAS.INT.BELGIUM.BE%3A80%2FFAS%2FOAUTH2 &STATE=AF0IFJSLDKJ &CLIENT_ID=MYCLIENTID Field Code Changed Figure 5: Example of authorize response 7

9 3 OpenID Connect Access Token request and Response 3.1 OPENID CONNECT ACCESS TOKEN REQUEST The OpenID Connect RFC states that there are 4 possible client authentication methods (used by Clients to authenticate to the Authorization Server when using the Token Endpoint) FAS will only support client_secret_basic as client authentication method Client Secret Basic The access token can be obtained by performing a POST request to the token endpoint of the FAS ( with the following parameters: Parameters grant_type MUST contain authorization_code code MUST contain The authorization code you received from the FAS redirect_uri MUST contain Same redirect uri as in the authorization code request And the following header: Authorization: Basic base64(clientid:clientsecret) URL: TYPE: POST HEADER: AUTHORIZATION: BASIC Y2XPZW50AWQ6Y2XPZW50C2VJCMV0 DATA: { "GRANT_TYPE : "AUTHORIZATION_CODE", "CODE : CODE, "REDIRECT_URI " : " Figure 6: Example of access token request Note : The content-type of the request should be x-www-form-urlencoded and NOT application/json. 8

10 3.2 OPENID CONNECT ACCESS TOKEN RESPONSE After receiving and validating a valid and authorized token request from the client, the Authorization Server returns a successful response that includes an ID Token an Access Token and a Refresh Token. The response uses the application/json media type. An example of such response can be found in Figure 7Figure 7. { "SCOPE":"PROFILE OPENID", "ACCESS_TOKEN": "SLAV32HKKG", REFRESH_TOKEN : ABSDGZEGSFVSD, "TOKEN_TYPE": "BEARER", "EXPIRES_IN": 3600, "ID_TOKEN": "EYJHBGCIOIJSUZI1NIISIMTPZCI6IJFLOWDKAZCIFQ.EWOGIMLZC YI6ICJODHRWOI8VC2VYDMVYLMV4YW1WBGUUY29TIIWKICJZDWIIOIAIMJQ4MJG5 NZYXMDAXIIWKICJHDWQIOIAICZZCAGRSA3F0MYISCIAIBM9UY2UIOIAIBI0WUZZ FV3PBMK1QIIWKICJLEHAIOIAXMZEXMJGXOTCWLAOGIMLHDCI6IDEZMTEYODA5NZ AKFQ.GGW8HZ1EUVLUXNUUIJKX_V8A_OMXZR0EHR9R6JGDQROOF4DAGU96SR_P6Q NQEGPE-GCCMG4VFKJKM8FCGVNZZUN4_KSP0AAP1TOJ1ZZWGJXQGBYKHIOTX7TPD QYHE5LCMIKPXFEIQILVQ0PC_E2DZL7EMOPWOAOZTF_M0_N0YZFC6G6EJBOEOROSD K5HODALRCVRYLSRQAZZKFLYUVCYIXEOV9GFNQC3_OSJZW2PAITHFUBEEBLUVVK4 XUVRWOLRLL0NX7RKKU8NXNHQ-RVKMZQG" Figure 7: Example of access token response The response of the server contains: The originally requested scopes The requested access token A refresh token that can be used to acquire a new access token (see section 5) The type of the token (defaults to Bearer) A duration before the token is expired and no longer usable in seconds An ID token, identifying the client (see below) The ID token is a JWT and is created (and thus signed) by the Authorization Server itself. The structure of this token is header content signature. { "TYP": "JWT", "KID": "7OR5FBLAXRPXTXAFRQXN+O7GK9S=", "ALG": "RS256" Figure 8: Header of decoded ID token 9

11 { "AT_HASH": "J3_BKFYWTWGHMKKD6UT10W", "SUB": " ", "AUDITTRACKINGID": "201109D4-437C-4C FA130B1EBAB-7490", "ISS": " "TOKENNAME": "ID_TOKEN", "AUD": "CLIENTID", "C_HASH": "WSKELV-N8ZCGTT2RG66KMQ", "ACR": "URN:BE:FEDICT:IAM:FAS:CITIZEN:LEVEL500", "ORG.FORGEROCK.OPENIDCONNECT.OPS": "CB3BA15E-0A75-4A66-8F1F- F2E4B50807A9", "AZP": "CLIENTID", "AUTH_TIME": , "REALM": "/", "EXP": , "TOKENTYPE": "JWTTOKEN", "IAT": Figure 9: Payload of decoded ID token The payload of the ID token contains information about the client and its request: The subject of the request (either the NRN, BIS number or an address) The issuer of the tokens (the authorization server) The intended audience of the tokens (in this case the client id) An authorization and expiry time of the token Other fields in the payload are not important and can be ignored safely. Signature of the ID token: TV9NNJH2FE2I_BWFQ0BGSKXASFJNVZRPTK88TJNV9FM Figure 10: Signature of the ID token Verifying the access token and the ID token Access token An endpoint is defined to retrieve metadata about a token, such as approved scopes and the context in which the token was issued. Field Code Changed Given an access token, a client can perform an HTTP POST on /oauth2/introspect?token=access_token to retrieve a JSON object indicating the following: active -> Is the token active. scope -> A space-separated list of the scopes associated with the token. client_id -> Client identifier of the client that requested the token. user_id -> The user who authorized the token. token_type -> The type of token. exp -> When the token expires, in seconds since January UTC. sub -> Subject of the token (NRN or BIS number) iss -> Issuer of the token. 10

12 The POST request must contain following parameters: Parameters token MUST contain The access token Value And the following header: Authorization: Basic base64(clientid:clientsecret) The /oauth2/introspect endpoint requires authentication, and supports basic authorization (a base64-encoded string of client_id:client_secret), client_id and client_secret passed as header values. The following example demonstrates the /oauth2/introspect endpoint with basic authorization: URL: TYPE: POST HEADER: AUTHORIZATION: BASIC Y2XPZW50AWQ6Y2XPZW50C2VJCMV0 DATA: { "TOKEN : "ACCESS TOKEN" Example response: { "ACTIVE": TRUE, "SCOPE": "PROFILE EGOVNRN", "CLIENT_ID": "MYOAUTH2CLIENT", "USER_ID": " ", "TOKEN_TYPE": "BEARER", "EXP": , "SUB": " "ISS": " Field Code Changed Field Code Changed If the access token is no longer valid you ll receive: { "ACTIVE": FALSE ID Token See section 'Validating a JWT token' for the general validation of a JWT token. 11

13 4 OpenID Connect User Info request and Response The user info endpoint can be called to retrieve additional user info using the access token. The user info response is a signed JWT token which will contain claims based on the requested scopes in the authorization code request. 4.1 OPENID CONNECT USER INFO REQUEST User info can be requested by performing a POST request to the user info endpoint of the FAS server ( The following parameters can/should be added: Parameters Value access_tokenauthorization MUST contain Bearer Access-Token Formatted: Highlight Figure 11: Example of user info request 4.2 OPENID CONNECT USER INFO RESPONSE If the access token is still valid, the FAS will return a signed JWT user info token. An example of such token and its contents can be found below. EYJBTECIOIJSUZI1NIISILRZUCI6IKPXVCISIKTJRCI6IJDPUJVGQKXBWFJQWFRYQUZSUVHOK083R0S5UZ0ILCJH BGCIOIJIUZI1NIJ9.EYJFR09WTLJOIJOIOTEYMTEZMJUZODQILCJDRVJUX0LTU1VFUII6ILNFUKLBTE5VTUJFUJ 0YMDE1MDQSIENOPUNJVELARU4GQ0ESIEM9QKUILCJDRVJUX1NVQKPFQ1QIOIJTRVJJQUXOVU1CRVI9 OTEXMJEZMJUZODQSR0LWRU5OQU1FPUPPSE4SU1VSTKFNRT1TTK9XLENOPUPPSE4GU05PVYAOQVVUS EVOVELDQVRJT04PLEM9QKUILCJDRVJUX1NFUKLBTE5VTUJFUII6IJKXMJEZMJUZODQILCJDRVJUX0NOIJOI SK9ITIBTTK9XICHBVVRIRU5USUNBVELPTIKILCJDRVJUX0DJVKVOTKFNRSI6IKPPSE4ILCJDRVJUX1NOIJOIU0 5PVYISIKNFULRFTUFJTCI6IK5VTEWIFQ.JPU5LGUCLXP/RHH0MQFWMSY/Y8UBFYXQ8I7EY9EXVDMDXOUJERL MJL+AA7SQZPGW6MWFQZSDNCLGN7OKS92BRX5MN1ODXMCIKKUPMZWRHWVEECQ23HTFFFRF1EASH3TC6 I4AK+OIOSZLCELSBSV9KM3RTOISN9+YRRCUAZUMKKTWHIJH8FLTA1JVFTFO+LDDDVUQCRRTMHS6MN/B9GBT 0FPLHKSVSKRCELGKHAMYO6ZWC8HDS Figure 12: Example User Info Response { "ALG": "RS256", "TYP": "JWT", "KID": "7OR5FBLAXRPXTXAFRQXN+O7GK9S=" Figure 13: Decoded header of example user info token 12

14 { "EGOVNRN": " ", "CERT_ISSUER": "SERIALNUMBER=201504, CN=CITIZEN CA, C=BE", "CERT_SUBJECT": "SERIALNUMBER= ,GIVENNAME=JOHN,SURNAME=SNOW,CN=JOHN SNOW (AUTHENTICATION),C=BE", "CERT_SERIALNUMBER": " ", "CERT_CN": "JOHN SNOW (AUTHENTICATION)", "CERT_GIVENNAME": "JOHN", "CERT_SN": "SNOW", "CERT_MAIL": NULL Figure 14: Decoded payload of example user info token JPU5LGUCLXP/RHH0MQFWMSY/Y8UBFYXQ8I7EY9EXVDMDXOUJERLMJL+AA7SQZPGW6MWFQZSDNCLGN7 OKS92BRX5MN1ODXMCIKKUPMZWRHWVEECQ23HTFFFRF1EASH3TC6I4AK+OIOSZLCELSBSV9KM3RTOISN9+Y RRCUAZUMKKTWHIJH8FLTA1JVFTFO+LDDDVUQCRRTMHS6MN/B9GBT0FPLHKSVSKRCELGKHAMYO6ZWC8HDS Figure 15: Signature of example user info token User Info Response Validation See section 'Validating a JWT token' for the general validation of a JWT token. 13

15 5 Requesting a new access token with a refresh token A new access token can be obtained by performing a POST request to the token endpoint of the FAS ( with the following parameters: Parameters grant_type MUST contain refresh_token refresh_token MUST contain The refresh token of the user you want to obtain a new access token for. And the following header: Authorization: Basic base64(clientid:clientsecret) URL: TYPE: POST HEADER: AUTHORIZATION: BASIC Y2XPZW50AWQ6Y2XPZW50C2VJCMV0 DATA: { "GRANT_TYPE : "REFRESH_TOKEN", "REFRESH_TOKEN : REFRESH-TOKEN After receiving and validating a valid and authorized refresh token request from the client, the Authorization Server returns a successful response that includes a new Access Token and a new Refresh Token. The response uses the application/json media type. { "ACCESS_TOKEN": "34847C38-CC17-46FE-991E AA856E", "REFRESH_TOKEN": "BDCFFBB B-BEA3-5FF7DCF07D31", "SCOPE": "EGOVNRN OPENID PROFILE", "ID_TOKEN": "EYAIDHLWIJOGIKPXVCISICJHBGCIOIAISFMYNTYIIH0.EYAIYXRFAGFZACI6ICJGEWC2NGU3D0I5CERWBWD2NE 1SYZB3IIWGINN1YII6ICJ5EWHXDGQ2CTDSCZJKNJK2NWEZYMO4BDEXEDZVMHZYDGZLDHUILCAIYXVKAXRUC MFJA2LUZ0LKIJOGIJIWYJUYMZBMLTQXOTETNGQ4NC05NZDLLWE2ZWI1M2U0MDRMZC01NZQILCAIAXNZIJ OGIMH0DHA6LY9PZHATCG9JLMLHBWZHCY5XYS5IZWXNAXVTLMJLOJGWL2ZHCY9VYXV0ADIILCAIDG9RZW5OY W1LIJOGIMLKX3RVA2VUIIWGIMF1ZCI6ICJPCGVUSUREZW1VUE9DIIWGIMFJCII6ICJ1CM46YMU6ZMVKAWN0 OMLHBTPMYXM6C3RHCJPZAXHKB3RZIIWGIM9YZY5MB3JNZXJVY2SUB3BLBMLKY29UBMVJDC5VCHMIOIAIM2QY YZA2ZTCTMTYXOS00NJDKLWE1NGMTZWIZMWVINDM1OWY1IIWGIMF6CCI6ICJPCGVUSUREZW1VUE9DII WGIMF1DGHFDGLTZSI6IDE0OTAWODCWMZUSICJYZWFSBSI6ICIVIIWGIMV4CCI6IDE0OTAWOTA2MZUSICJ0B 2TLBLR5CGUIOIAISLDUVG9RZW4ILCAIAWF0IJOGMTQ5MDA4NZAZNSB9.HFHWAWDKFMDGCPN8L7DKXMDN SHTSGXLGJWCCDQN26YW", "TOKEN_TYPE": "BEARER", "EXPIRES_IN":

16 6 Validating a JWT token A JWT received from the authorization server has to be validated to ensure the content, sender and validity of the token. 6.1 CHECKING THE CONTENT OF THE TOKEN The Issuer (the appropriate FAS url) MUST exactly match the value of the iss (issuer) Claim. The Client MUST validate that the aud (audience) Claim contains its client_id value registered at the Issuer identified by the iss (issuer) Claim as an audience. The ID Token MUST be rejected if the ID Token does not list the Client as a valid audience, or if it contains additional audiences not trusted by the Client. The alg value SHOULD be the default of RS256. The current time MUST be before the time represented by the exp Claim. The iat Claim can be used to reject tokens that were issued too far away from the current time, limiting the amount of time that nonces need to be stored to prevent attacks. The acceptable range is Client specific. If a nonce value was sent in the Authentication Request, a nonce Claim MUST be present and its value checked to verify that it is the same value as the one that was sent in the Authentication Request. The Client SHOULD check the nonce value for replay attacks. 6.2 CHECKING THE SIGNATURE OF THE TOKEN As mentioned before, a JWT consists of three different parts separated by a dot: the header, the payload and the signature. In order to check the authenticity of the token we will need the all three parts of the token. We will check the signature against the contents of the token to ensure the signature corresponds to this token. During this check the public key of the authorization server will be used. This will ensure that token was signed by the authorization server and not by a malicious party. 15

17 6.2.1 Obtain the public key The public key of the authorization server can be created via the modulus and the exponent found at the JWK URI: A get request to the above URL will respond with an application/json object containing an array of json objects containing the following: Kty: The type of the public key Kid: the id of this key object Use: The use of this key (e.g.: sig(nature)) Alg: The specific signing algorithm N: The modulus of the public key E: The exponent of the public key With this information, the public key can be reconstructed with the modulus and the exponent. Since the jwk URL returns an array of key objects, we have to find the correct key. We do this with the kid field in the header of the jwt token. This value should match with one of the kid fields of the key objects in the array. This is the key object of which we will use the exponent and modulus. Example given in JAVA: public static PublicKey getpublickey(string modulusb64u, String exponentb64u) throws Exception { byte exponentb[] = Base64.getUrlDecoder().decode(exponentB64u); byte modulusb[] = Base64.getUrlDecoder().decode(modulusB64u); BigInteger exponent = new BigInteger(toHexFromBytes(exponentB), 16); BigInteger modulus = new BigInteger(toHexFromBytes(modulusB), 16); //Build the public key RSAPublicKeySpec spec = new RSAPublicKeySpec(modulus, exponent); KeyFactory factory = KeyFactory.getInstance("RSA"); PublicKey pub = factory.generatepublic(spec); return pub; Figure 16: Example of public key builder 16

18 6.2.2 Check the signature Once the public key is obtained, it can be used to verify the signature of the token. Example given in JAVA: public boolean verifyjwt (String exponentb64u, String modulusb64u,string jwt) throws Exception{ //Build the public key from modulus and exponent PublicKey publickey = getpublickey (modulusb64u,exponentb64u); //print key as PEM (base64 and headers) String publickeypem = "-----BEGIN PUBLIC KEY-----\n" + Base64.getEncoder().encodeToString(publicKey.getEncoded()) +"\n" + "-----END PUBLIC KEY-----"; System.out.println( publickeypem); //get signed data and signature from JWT String signeddata = jwt.substring(0, jwt.lastindexof(".")); String signatureb64u = jwt.substring(jwt.lastindexof(".")+1,jwt.length()); byte signature[] = Base64.getUrlDecoder().decode(signatureB64u); //verify Signature Signature sig = Signature.getInstance("SHA256withRSA"); sig.initverify(publickey); sig.update(signeddata.getbytes()); boolean v = sig.verify(signature); return v; Figure 17: Example of JWT verifier If the signature is valid we can assume the signature belongs to the JWT token and that is was signed by the authorization server. In that case we can continue. If not, an error message should be returned to the client. 17

19 7 OIDC Logout Terminating an OIDC session on the authorization server is done via a single GET call to: The following parameters can/should be added: Parameters Value id_token_hint MUST contain The session ID_token (see 3.2) post_logout_redirect_uri* SHALL include The https scheme (*)Make sure the post_logout_redirect_uri is communicated during the onboarding process. We need to whitelist the post logout redirect uri for each relying party. ID_TOKEN_HINT =EYJHBGCIOIJSUZI1NIISIMTPZCI6IJFLOWDKAZCIFQ.EWOGIMLZC YI6ICJODHRWOI8VC2VYDMVYLMV4YW1WBGUUY29TIIWKICJZDWIIOIAIMJQ4MJG5 NZYXMDAXIIWKICJHDWQIOIAICZZCAGRSA3F0MYISCIAIBM9UY2UIOIAIBI0WUZZ FV3PBMK1QIIWKICJLEHAIOIAXMZEXMJGXOTCWLAOGIMLHDCI6IDEZMTEYODA5NZ AKFQ.GGW8HZ1EUVLUXNUUIJKX_V8A_OMXZR0EHR9R6JGDQROOF4DAGU96SR_P6Q NQEGPE-GCCMG4VFKJKM8FCGVNZZUN4_KSP0AAP1TOJ1ZZWGJXQGBYKHIOTX7TPD QYHE5LCMIKPXFEIQILVQ0PC_E2DZL7EMOPWOAOZTF_M0_N0YZFC6G6EJBOEOROSD K5HODALRCVRYLSRQAZZKFLYUVCYIXEOV9GFNQC3_OSJZW2PAITHFUBEEBLUVVK4 XUVRWOLRLL0NX7RKKU8NXNHQ- RVKMZQG&POST_LOGOUT_REDIRECT_URI= Figure 18: Example of user endsession request Make sure you terminate the local session before redirecting towards the endsession endpoint of the FAS. We ll redirect the user to the post_logout_redirect_uri after we ve terminated the user s FAS session. 18