Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
Last revision Both sides next revision
devel:documentation:security:dev:security [2021/02/23 13:54]
kucerar cas since information 		devel:documentation:security:dev:security [2023/12/01 16:18]
chalupat [Single logout flow from IDM]
Line 2: Line 2:
  
 ===== Dictionary terms ===== ===== Dictionary terms =====
-  * **Base permission** - basic permission, e.g. ''READ'', ''CREATE'', ''UPDATE'', ''DELETE'' 
-  * **Group permission** - group permission could contain base permissions. Group is related to some domain object, e.g. ''IDENTITY'', ''ROLE''  
-  * **Authority** - Group + base permission, e.g. ''IDENTITY\_READ'', ''ROLE\_CREATE''. Authority is granted to identity by authentication. 
- 
  
 +  * **Base permission**  - basic permission, e.g. ''READ'', ''CREATE'', ''UPDATE'', ''DELETE''
 +  * **Group permission**  - group permission could contain base permissions. Group is related to some domain object, e.g. ''IDENTITY'', ''ROLE''
 +  * **Authority**  - Group + base permission, e.g. ''IDENTITY\_READ'', ''ROLE\_CREATE''. Authority is granted to identity by authentication.
 ===== API authentication ===== ===== API authentication =====
  
Line 21: Line 20:
   * if credentials do not match, pass request to another filter in chain   * if credentials do not match, pass request to another filter in chain
  
-In reality there is only one authentication servlet filter - ''%%AuthenticationFilter%%''. Others filters are Spring beans implementing ''%%IdmAuthenticationFilter%%'' interface. An exception in filters is the ''%%ExtendExpirationFilter%%'', which is another servlet filter handling the extension of expiration date of JWT tokens. This filter also controls possible exceptions in authentication flow.+In reality there is only one authentication servlet filter - ''<nowiki>AuthenticationFilter</nowiki>''. Others filters are Spring beans implementing ''<nowiki>IdmAuthenticationFilter</nowiki>''  interface. An exception in filters is the ''<nowiki>ExtendExpirationFilter</nowiki>'', which is another servlet filter handling the extension of expiration date of JWT tokens. This filter also controls possible exceptions in authentication flow.
  
 ==== API endpoints ==== ==== API endpoints ====
Line 27: Line 26:
 There are 2 endpoints for successful user login: There are 2 endpoints for successful user login:
  
-  * /authentication - POST, public -  authentication, returns JWT token+  * /authentication - POST, public - authentication, returns JWT token
   * /authentication/remote-auth - GET, secured - authentication against external service, returns JWT token and expects the user to be successfully authenticated by one of filters   * /authentication/remote-auth - GET, secured - authentication against external service, returns JWT token and expects the user to be successfully authenticated by one of filters
  
 And one endpoint for user logout: And one endpoint for user logout:
-  * /authentication - DELETE - logout with used JWT token (=> disable used JWT token)+ 
 +  * /authentication - DELETE - logout with used JWT token (⇒ disable used JWT token)
  
 In case of successful request on the endpoint, the token is passed in HTTP response header. Respose header is called ''CIDMST''. In case of successful request on the endpoint, the token is passed in HTTP response header. Respose header is called ''CIDMST''.
Line 37: Line 37:
 ==== Implemented authentication filters ==== ==== Implemented authentication filters ====
  
-Filter do not check authorization or user's permissions, just validate the request data, transform these and pass them to Authentication Managers. There are following filters in IdM core (the //core// module):+Filter do not check authorization or user's permissions, just validate the request data, transform these and pass them to Authentication Managers. There are following filters in IdM core (the //core//  module):
  
   * BasicIdMAuthenticationFilter   * BasicIdMAuthenticationFilter
-    * HTTP Basic authentication, login, and password are base64 encoded in HTTP header "Authorization" prefixed by "Basic ", according to [[https://tools.ietf.org/html/rfc2617#page-5|RFC 2617]] +      * HTTP Basic authentication, login, and password are base64 encoded in HTTP header "Authorization" prefixed by "Basic ", according to [[https://tools.ietf.org/html/rfc2617#page-5|RFC 2617]] 
-    * internal API transforms the login and password and passes them to Authorization Manager +      * internal API transforms the login and password and passes them to Authorization Manager 
-    * enabled by default+      * enabled by default
   * JwtIdMAuthenticationFilter   * JwtIdMAuthenticationFilter
-    * validates IdM JWT token (read as "jot") +      * validates IdM JWT token (read as "jot") 
-    * tokens without expiration are taken as valid +      * tokens without expiration are taken as valid 
-    * HMAC256 +      * HMAC256 
-    * enabled by default+      * enabled by default
   * SsoIdmAuthenticationFilter   * SsoIdmAuthenticationFilter
-    * used mainly for AD SSO authentication, expects configured web server in front of IdM which handles Kerberos authentication +      * used mainly for AD SSO authentication, expects configured web server in front of IdM which handles Kerberos authentication 
-    * processes the result of the authentication in the HTTP header "REMOTE_USER" +      * processes the result of the authentication in the HTTP header "REMOTE_USER" 
-    * **disabled by default**, can be enabled by the configuration property ''idm.sec.core.authentication-filter.core-sso-authentication-filter.enabled=true''+      * **disabled by default**, can be enabled by the configuration property ''idm.sec.core.authentication-filter.core-sso-authentication-filter.enabled=true''
   * //external authentication server//   * //external authentication server//
-    * CzechIdM is ready to authenticate users based on external resource +      * CzechIdM is ready to authenticate users based on external resource 
-    * external filters are based on the same principles mentioned above +      * external filters are based on the same principles mentioned above 
-    * primary purpose is to issue the internal IdM JWT token to user using the remote-auth endpoint +      * primary purpose is to issue the internal IdM JWT token to user using the remote-auth endpoint 
-    * filter behaves quite permissively - if user accesses other endpoints then those for authentication, the filter signs the user in for each request and completes the request (if the user is authorized)+      * filter behaves quite permissively - if user accesses other endpoints then those for authentication, the filter signs the user in for each request and completes the request (if the user is authorized)
   * CasIdmAuthenticationFilter   * CasIdmAuthenticationFilter
-    * @since 10.9.0 +      * @since 10.9.0 
-    * Used for SSO against CAS +      * Used for SSO against CAS 
-    * CAS need to be configured correctly - see tutorial TODO +      * CAS need to be configured correctly - see tutorial TODO 
-    * By default this filter is disabled +      * By default this filter is disabled 
-    * **Don't override this property on FE, otherwise you can end up without option how to login (if CAS is broken). Enable it only directly in application.properties** +      * **Don't override this property on FE, otherwise you can end up without option how to login (if CAS is broken). Enable it only directly in application.properties** 
-    * Can be enabled by configuration property ''idm.pub.core.cas.sso.enabled=true''+      * Can be enabled by configuration property ''idm.pub.core.cas.sso.enabled=true''
  
 ===== Authorization and JWT token ===== ===== Authorization and JWT token =====
Line 76: Line 76:
   * iat - issued at date   * iat - issued at date
  
 +All IdM JWT tokens are signed using HMAC256 algorithm. The symmetric encryption key is configuration property of CzechIdM, stored as "idm.sec.security.jwt.secret.token". Default token expiration time is 10 hours (idm.sec.security.jwt.expirationTimeout). JWT tokens are persisted in database (''<nowiki>IdmToken</nowiki>''  entity) with assigned authorities. When identity is logged out, token is disabled. Disabled and expired tokens are purged periodically by internal scheduled task.
  
-All IdM JWT tokens are signed using HMAC256 algorithm. The symmetric encryption key is configuration property of CzechIdM, stored as "idm.sec.security.jwt.secret.token". Default token expiration time is 10 hours (idm.sec.security.jwt.expirationTimeout). JWT tokens are persisted in database (''%%IdmToken%%'' entity) with assigned authorities. When identity is logged out, token is disabled. Disabled and expired tokens are purged periodically by internal scheduled task.+Backend of CzechIdM supports immediate detection of user's authorization change. Each modification type is implemented as application event processor, for further details please check the source code and tests :) When user's authorization changes, then persisted tokens, which user owns, are disabled ⇒ user is logged out. Types of modifications:
  
-Backend of CzechIdM supports immediate detection of user's authorization change. Each modification type is implemented as application event processor, for further details please check the source code and tests :) When user's authorization changes, then persisted tokens, which user owns, are disabled => user is logged out. Types of modifications: +  * removal of role, which carries application permissions ⇒ user losses some permission.
- +
-  * removal of role, which carries application permissions => user losses some permission.+
   * disabling the user   * disabling the user
   * role's permissions change - revokes tokens of all users which have the role assigned   * role's permissions change - revokes tokens of all users which have the role assigned
Line 89: Line 88:
 Token can be used instead of a basic authentication to authenticate to the CzechIdM API. Token can be obtainted by [[#api_endpoints|authentication endpoints]] above or can be generated from application (token agenda was added @since 10.8.0 version): Token can be used instead of a basic authentication to authenticate to the CzechIdM API. Token can be obtainted by [[#api_endpoints|authentication endpoints]] above or can be generated from application (token agenda was added @since 10.8.0 version):
  
-{{ :devel:documentation:security:dev:generate-token-detail.png |}}+{{  .:generate-token-detail.png  }}
  
 Use token agenda for generate system tokens, those can be used for system to system communication. Token expiration can be set optionally, but is not required. Token will grant the same authorities and permissions as token owner. Use token agenda for generate system tokens, those can be used for system to system communication. Token expiration can be set optionally, but is not required. Token will grant the same authorities and permissions as token owner.
  
 If you have a valid token, you can use it, for example to get all identities: If you have a valid token, you can use it, for example to get all identities:
- 
 <code> <code>
 +
 curl -X GET "http://localhost:8080/idm-backend/api/v1/identities" -H  "accept: */*" -H  "CIDMST: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.ew0KICAiaWQiIDogIjMwNmJlMWMyLTNmZTItNDZlMy1hYzkwLTExZmI1NTA1ZDYwZSIsDQogICJjdXJyZW50VXNlcm5hbWUiIDogImFkbWluIiwNCiAgImN1cnJlbnRJZGVudGl0eUlkIiA6ICJkNDE0YTA5MS0zODE1LTQzOWQtOWVjNi1iZWQ4MTlmZWE0MzkiLA0KICAib3JpZ2luYWxVc2VybmFtZSIgOiAiYWRtaW4iLA0KICAib3JpZ2luYWxJZGVudGl0eUlkIiA6ICJkNDE0YTA5MS0zODE1LTQzOWQtOWVjNi1iZWQ4MTlmZWE0MzkiLA0KICAiZnJvbU1vZHVsZSIgOiAiY29yZSIsDQogICJleHBpcmVkIiA6IGZhbHNlLA0KICAiZXhwIiA6IG51bGwsDQogICJpYXQiIDogIjIwMjEtMDEtMjVUMTA6MDk6NTYuODk1KzAxOjAwIg0KfQ.4duJJb5pJDfJvXmdk259gW92fkjzqEr8ya9VqVJ3jCo" curl -X GET "http://localhost:8080/idm-backend/api/v1/identities" -H  "accept: */*" -H  "CIDMST: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.ew0KICAiaWQiIDogIjMwNmJlMWMyLTNmZTItNDZlMy1hYzkwLTExZmI1NTA1ZDYwZSIsDQogICJjdXJyZW50VXNlcm5hbWUiIDogImFkbWluIiwNCiAgImN1cnJlbnRJZGVudGl0eUlkIiA6ICJkNDE0YTA5MS0zODE1LTQzOWQtOWVjNi1iZWQ4MTlmZWE0MzkiLA0KICAib3JpZ2luYWxVc2VybmFtZSIgOiAiYWRtaW4iLA0KICAib3JpZ2luYWxJZGVudGl0eUlkIiA6ICJkNDE0YTA5MS0zODE1LTQzOWQtOWVjNi1iZWQ4MTlmZWE0MzkiLA0KICAiZnJvbU1vZHVsZSIgOiAiY29yZSIsDQogICJleHBpcmVkIiA6IGZhbHNlLA0KICAiZXhwIiA6IG51bGwsDQogICJpYXQiIDogIjIwMjEtMDEtMjVUMTA6MDk6NTYuODk1KzAxOjAwIg0KfQ.4duJJb5pJDfJvXmdk259gW92fkjzqEr8ya9VqVJ3jCo"
 +
 </code> </code>
 +
 ==== TokenManager ==== ==== TokenManager ====
  
-''%%TokenManager%%'' is used for creating IdM tokens. Token can be created for different purpose (token type). When token is used, can be disabled (e.g. logout, one time usage).+''<nowiki>TokenManager</nowiki>''  is used for creating IdM tokens. Token can be created for different purpose (token type). When token is used, can be disabled (e.g. logout, one time usage).
  
 ===== Token expiration extension ===== ===== Token expiration extension =====
  
-By default both frontend (FE) and backend (BE) automatically extend the expiration of IdM JWT. In case of successful GET request on API, the token expiration is extended on BE and passed in HTTP response (watch out for CORS, has to be explicitly allowed, since the HTTP header is called "CIDMST"). FE (''%%RestApiService.js%%'') automatically disassembles the response looking for auth. token. If token is present, it is set as new token which shall be used for new API requests (done in ''%%App.js%%''). Expiration is extended in one minute window - when token has expiration at least one minute older than new one (prevent to persist token every api call).+By default both frontend (FE) and backend (BE) automatically extend the expiration of IdM JWT. In case of successful GET request on API, the token expiration is extended on BE and passed in HTTP response (watch out for CORS, has to be explicitly allowed, since the HTTP header is called "CIDMST"). FE (''<nowiki>RestApiService.js</nowiki>'') automatically disassembles the response looking for auth. token. If token is present, it is set as new token which shall be used for new API requests (done in ''<nowiki>App.js</nowiki>''). Expiration is extended in one minute window - when token has expiration at least one minute older than new one (prevent to persist token every api call).
  
 Developer tip: do not trust the console, especially while working with promises: Developer tip: do not trust the console, especially while working with promises:
Line 116: Line 117:
   console.log(response.headers); // prints '{}', object looks empty   console.log(response.headers); // prints '{}', object looks empty
 } }
 +
 </code> </code>
  
Line 122: Line 124:
 @since 10.5.0 @since 10.5.0
  
-User with authority ''IDENTITY_SWITCHUSER'' can login as different user. Feature is usable for checking application behavior under selected user (e.g. helpdesk). Logged user needs to have permission ''SWITCHUSER'' to select target user. +User with authority ''IDENTITY_SWITCHUSER''  can login as different user. Feature is usable for checking application behavior under selected user (e.g. helpdesk). Logged user needs to have permission ''SWITCHUSER''  to select target user. Feature is available from user main menu in application - any other active user can be selected and currently logged user will be logged as selected used.
-Feature is available from user main menu in application - any other active user can be selected and currently logged user will be logged as selected used. +
  
 Currently logged user token (see above) is filled with selected user authorities - original user is preserved as token owner. Return back (logout) to originally logged user is available from user main menu too. Currently logged user token (see above) is filled with selected user authorities - original user is preserved as token owner. Return back (logout) to originally logged user is available from user main menu too.
  
-{{ :devel:documentation:security:dev:switch-user.png?600 |}}+{{  .:switch-user.png?600  }} 
 ===== Enforce password change ===== ===== Enforce password change =====
  
Line 135: Line 137:
  
 <note tip>Flag for enforce password change can be filled by project processors (see password change, reset and generate events) or by GUI (flag added to password detail).</note> <note tip>Flag for enforce password change can be filled by project processors (see password change, reset and generate events) or by GUI (flag added to password detail).</note>
 +
 ===== SSO ===== ===== SSO =====
  
 SSO support on FE is implemented by issuing the internal IdM JWT without the need to type in user's credentials. This is done by sending a "prerequest" onto secured /authentication/remote-auth endpoint, accessible only to authenticated users. The authentication itself must be done in one of auth filters. SSO support on FE is implemented by issuing the internal IdM JWT without the need to type in user's credentials. This is done by sending a "prerequest" onto secured /authentication/remote-auth endpoint, accessible only to authenticated users. The authentication itself must be done in one of auth filters.
  
-We expect either HTTP header or Cookie to be the bearer of the remote authentication data. When the user accesses IdM, FE first tries to sign him in using the ''%%remote-auth%%''. The ''%%remote-auth%%'' attempt is done only on first access to CzechIdM, token expiration, authority change or user login.+We expect either HTTP header or Cookie to be the bearer of the remote authentication data. When the user accesses IdM, FE first tries to sign him in using the ''<nowiki>remote-auth</nowiki>''. The ''<nowiki>remote-auth</nowiki>''  attempt is done only on first access to CzechIdM, token expiration, authority change or user login.
  
-SSO authentication to AD domain can be configured with the help of SsoIdmAuthenticationFilter and Apache web server, which is installed in front of IdM. For more details about SSO configuration see [[tutorial:adm:sso_ad_domain|SSO install guide]].+SSO authentication to AD domain can be configured with the help of SsoIdmAuthenticationFilter and Apache web server, which is installed in front of IdM. For more details about SSO configuration see [[:tutorial:adm:sso_ad_domain|SSO install guide]].
  
 ===== Two-factor authentication ===== ===== Two-factor authentication =====
Line 147: Line 150:
 @since 10.7.0 @since 10.7.0
  
-Feature is available from user profile (user main menu) in application. Two-factor authentication  is optional and can be enabled from user profile:+Feature is available from user profile (user main menu) in application. Two-factor authentication is optional and can be enabled from user profile:
  
-{{ :devel:documentation:security:dev:two-factor-profile.png |}}+{{  .:two-factor-profile.png  }}
  
-After user sign in to CzechIdM using username and password, user will be prompted to provide an authentication code from a text message (notification) or from TOTP application. CzechIdM  will only ask to provide two-factor authentication code again if user have logged out, is using a new device, or user session expires.+After user sign in to CzechIdM using username and password, user will be prompted to provide an authentication code from a text message (notification) or from TOTP application. CzechIdM will only ask to provide two-factor authentication code again if user have logged out, is using a new device, or user session expires.
  
 Supported methods to get authentication code: Supported methods to get authentication code:
  
-* **Application** - authentication code is generated by TOTP application (Google Authenticator, TOTP Authenticator, FreeOTP etc.). +* **Application**  - authentication code is generated by TOTP application (Google Authenticator, TOTP Authenticator, FreeOTP etc.). * **Sms notification**  - authentication code is send by standard IdM notification. **Sms notifications have to be supported**  to use this method ([[..:..:modules_sms|sms notification sender]] needs to be provided).
-* **Sms notification** - authentication code is send by standard IdM notification. **Sms notifications have to be supported** to use this method ([[..:..:modules_sms|sms notification sender]] needs to be provided).+
  
 The first authentication code obtained by selected method is needed to enable using two-factor authentication: The first authentication code obtained by selected method is needed to enable using two-factor authentication:
  
-{{ :devel:documentation:security:dev:two-factor-confirm.png |}}+{{  .:two-factor-confirm.png  }}
  
 <note tip>HTTP Basic authentication cannot be used with two-factor authentication enabled.</note> <note tip>HTTP Basic authentication cannot be used with two-factor authentication enabled.</note>
Line 172: Line 174:
 === Configuration === === Configuration ===
  
-Basic configuration is available by [[..:..:application_configuration:dev:backend#two-factor_authentication|application properties]]. +Basic configuration is available by [[..:..:application_configuration:dev:backend#two-factor_authentication|application properties]].
  
-Advanced: Is possible to change [[https://github.com/samdjstevens/java-totp/tree/master/totp-spring-boot-starter|default SHA1 hashing algoritm]] (~provide different hashing algorithm as spring bean) and [[https://github.com/samdjstevens/java-totp/tree/master/totp-spring-boot-starter#code-length|default 6-digit verification code length]] (~change frontend localization) programatically. +Advanced: Is possible to change [[https://github.com/samdjstevens/java-totp/tree/master/totp-spring-boot-starter|default SHA1 hashing algoritm]] (~provide different hashing algorithm as spring bean) and [[https://github.com/samdjstevens/java-totp/tree/master/totp-spring-boot-starter#code-length|default 6-digit verification code length]] (~change frontend localization) programatically.
  
 ===== CAS authentication ===== ===== CAS authentication =====
Line 182: Line 184:
 This feature is disabled by default. If you want to enable it, see configuration properties [[..:..:application_configuration:dev:backend#two-cas_authentication_filter|application]] This feature is disabled by default. If you want to enable it, see configuration properties [[..:..:application_configuration:dev:backend#two-cas_authentication_filter|application]]
  
-You need to have working CAS - You are able to log in directly to CAS. +You need to have working CAS - You are able to log in directly to CAS. Cas will return username of authenticated user. This username for CAS must be same as username in IdM.
-Cas will return username of authenticated user. This username for CAS must be same as username in IdM.+
  
-Other then that, you need to configure CAS. Mandatory CAS configuration is below +Other then that, you need to configure CAS. Mandatory CAS configuration is below cas.properties
-cas.properties+
 <code> <code>
 +
 ... ...
 cas.client.validator-type=CAS30 cas.client.validator-type=CAS30
Line 196: Line 197:
 cas.logout.followServiceRedirects=true cas.logout.followServiceRedirects=true
 ... ...
 +
 </code> </code>
  
 idm-200.json idm-200.json
 +
 <code> <code>
 { {
Line 207: Line 210:
   "evaluationOrder" : 1   "evaluationOrder" : 1
 } }
 +
 </code> </code>
  
-When all configuration is done. You will be able to log into IdM **ONLY** via CAS.   +When all configuration is done. You will be able to log into IdM **ONLY**  via CAS. **The authentication flow is**: Access IdM URL → if you are not logged in → redirect to CAS → log in → redirect back to IdM → You are authenticated in IdM Access IdM URL → If you are logged in (jwt token is valid) → You are authenticated in IdM **Logout:**  Click on logout button in IdM → Log out of IdM → CAS logout URL is called → logout from CAS → redirect to IdM → Redirect back to CAS because you are not authenticated **Expired jwt token:**  Logged out of IdM → redirect to /login → CAS is conntacted → authentication flow is applied now 
-**The authentication flow is**:   + 
-Access IdM URL -> if you are not logged in -> redirect to CAS -> log in -> redirect back to IdM -> You are authenticated in IdM   +===== OIDC authentication ===== 
-Access IdM URL -> If you are logged in (jwt token is valid) -> You are authenticated in IdM   + 
-**Logout:**   +@since 13.1.0 
-Click on logout button in IdM -> Log out of IdM -> CAS logout URL is called -> logout from CAS -> redirect to IdM -> Redirect back to CAS because you are not authenticated   + 
-**Expired jwt token:**   +This feature is disabled by default. If you want to enable it, see configuration properties [[this>devel/documentation/application_configuration/dev/backend#oidc_authentication|application]] 
-Logged out of IdM -> redirect to /login -> CAS is conntacted -> authentication flow is applied now  + 
 +CAS Service for OIDC configuration: 
 + 
 +idm-oidc-201.json 
 +<code> 
 + 
 +{ 
 +  "@class" : "org.apereo.cas.services.OidcRegisteredService", 
 +  "clientId" : "client", 
 +  "clientSecret": "secret", 
 +  "serviceId" : "redirectUrl", 
 +  "name" : "CzechIdM OIDC", 
 +  "id" : 201, 
 +  "evaluationOrder" : 1, 
 +  "scopes": ["java.util.HashSet", ["openid"]], 
 +  "supportedResponseTypes": ["java.util.HashSet", ["code"]], 
 +  "logoutType": "BACK_CHANNEL", 
 +  "logoutUrl": "logoutUrl", 
 +  "redirectUrl": "redirectUrl" 
 +} 
 + 
 +</code> 
 + 
 + 
 +==== The authentication flow from front ==== 
 + 
 +{{  .:oidc_1.png?nolink&1061x612  }} 
 + 
 +1) User isn't authenticated so frotend redirects user to api endpoint for OIDC login. 
 + 
 +2) IDM redirects user to OIDC providers login page (adress from .well-known endpoint on OIDC providers or can be overwritten in config) 
 + 
 +3) User login on OIDC providers page 
 + 
 +4) User gets redirected back to IDM with "code" 
 + 
 +5) IDM uses "code" to get from OIDC provider, ID token and Access token (adress from .well-known endpoint on OIDC providers or can be overwritten in config) 
 + 
 +6) After validation IDM creates CIDMST token (with externalID set to SID) 
 + 
 +7) IDM redirects to front with CIDMST 
 + 
 + 
 +==== The authentication flow from external application (hub, ...) ==== 
 + 
 +{{  .:oidc2_1.png?nolink&889x698  }} 
 + 
 +1) Authentication happens on external application 
 + 
 +2) When accessing a resource, external application presents access token (in header "Authorization" and value starts with "Bearer") 
 + 
 +3) IDM validates token on OIDC provider 
 + 
 +4) If user has access to resource returns it 
 + 
 + 
 +==== Single logout flow from IDM ==== 
 + 
 +{{  .:oidc3_1.png?nolink&881x369  }} 
 + 
 +1) User clicks on logout button so front redirects him to api endpoint for OIDC logout. 
 + 
 +2) IDM redirect him to logout endpoint on OIDC provider (adress from .well-known endpoint on OIDC providers or can be overwritten in config) 
 + 
 +3) OIDC provider calls IMD and IDM invalidates all tokens with SID (from JWT token) 
 + 
  • by chalupat