{"id":40865,"date":"2020-02-05T10:07:04","date_gmt":"2020-02-05T07:07:04","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/sso-na-mikroservisnoj-arhitekture-ispolzuem-keycloak-chast-%e2%84%961"},"modified":"2020-02-05T10:07:04","modified_gmt":"2020-02-05T07:07:04","slug":"sso-na-mikroservisnoj-arhitekture-ispolzuem-keycloak-chast-%e2%84%961","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/sso-na-mikroservisnoj-arhitekture-ispolzuem-keycloak-chast-%e2%84%961","title":{"rendered":"SSO on microservices architecture. Using Keycloak. Part #1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>In any large company, including X5 Retail Group, as it develops, the number of projects requiring user authentication increases. Over time, a seamless transition for users from one application to another becomes necessary, leading to the need for a unified Single-Sign-On (SSO) server. However, what do you do when identity providers like AD or others, lacking additional attributes, are already in use across various projects? This is where a class of systems known as \"identity brokers\" comes into play. The most functional representatives of this class include Keycloak, Gravitee Access Management, and others. The use cases can vary widely, including machine interactions, user participation, etc. The solution must support flexible and scalable functionality that can combine all requirements into one, and our company's current solution is the identity broker \u2013 Keycloak. <\/p>\n<p><img decoding=\"async\" alt=\"SSO on microservices architecture. Using Keycloak. Part #1\" src=\"\/wp-content\/uploads\/2020\/02\/3a7f1d5f68fa5d07fc30f2804dc62bef.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nKeycloak is an open-source product designed for identity and access management, supported by RedHat. It serves as the backbone for the company's products utilizing SSO \u2013 RH-SSO.<\/p>\n<h3>Basic concepts <\/h3>\n<p>\nBefore delving into solutions and approaches, it is essential to clarify terms and the sequence of processes:<\/p>\n<p><img decoding=\"async\" alt=\"SSO on microservices architecture. Using Keycloak. Part #1\" src=\"\/wp-content\/uploads\/2020\/02\/3a83d4364425aeed1019662fd1d5f152.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Identification<\/b> \u2014 this is the procedure of recognizing a subject by their identifier (in simpler terms, it's determining the name, username, or number).<\/p>\n<p><b>Authentication<\/b> \u2014 this is the procedure of authentication (users are verified using passwords, emails are verified with digital signatures, etc.)<\/p>\n<p><b>Authorization<\/b> \u2014 this is granting access to a resource (for example, to email).<\/p>\n<h4>Identity broker Keycloak<\/h4>\n<p>\n<b>Keycloak<\/b> \u2014 is an open-source solution for identity and access management, intended for use in information systems where microservices architectural patterns may be employed.<\/p>\n<p>Keycloak offers features such as Single Sign-On (SSO), brokered identity, social login, user federation, client adapters, an admin console, and an account management console.<\/p>\n<p>The basic functionality supported in Keycloak includes:<\/p>\n<ul>\n<li>Single Sign-On and Single Sign-Out for web applications.<\/li>\n<li>Support for OpenID\/OAuth 2.0\/SAML.<\/li>\n<li>Identity Brokering \u2013 authentication using external OpenID Connect or SAML identity providers.<\/li>\n<li>Social Login \u2013 support for Google, GitHub, Facebook, Twitter for user identification.<\/li>\n<li>User Federation \u2013 synchronization of users from LDAP and Active Directory servers and other identity providers.<\/li>\n<li>Kerberos bridge \u2013 using a Kerberos server for automatic user authentication.<\/li>\n<li>Admin Console \u2014 for centralized management of settings and parameters through the Web.<\/li>\n<li>Account Management Console \u2013 for self-management of user profiles.<\/li>\n<li>Customization of the solution based on the company's branding.<\/li>\n<li>2FA Authentication \u2013 support for TOTP\/HOTP using Google Authenticator or FreeOTP.<\/li>\n<li>Login Flows \u2013 self-registration of users, password recovery and reset, and more.<\/li>\n<li>Session Management \u2013 administrators can manage user sessions from a single point.<\/li>\n<li>Token Mappers \u2013 mapping user attributes, roles, and other required attributes into tokens.<\/li>\n<li>Flexible policy management through realm, application, and user.<\/li>\n<li>CORS Support \u2013 client adapters have built-in CORS support.<\/li>\n<li>Service Provider Interfaces (SPI) \u2013 a wide range of SPIs allowing configuration of various aspects of server operation: authentication flows, identity providers, protocol mappings, and more.<\/li>\n<li>Client adapters for JavaScript applications, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.<\/li>\n<li>Support for various applications that work with OpenID Connect Relying Party library or SAML 2.0 Service Provider Library.<\/li>\n<li>Expandable through the use of plugins.<\/li>\n<\/ul>\n<p>\nFor CI\/CD processes, as well as automation of management processes in Keycloak, REST API\/JAVA API can be used. Documentation is available electronically: <\/p>\n<p>REST API <noindex><a rel=\"nofollow\" href=\"https:\/\/www.keycloak.org\/docs-api\/8.0\/rest-api\/index.html\">https:\/\/www.keycloak.org\/docs-api\/8.0\/rest-api\/index.html<\/a><\/noindex><br \/>\nJAVA API <noindex><a rel=\"nofollow\" href=\"https:\/\/www.keycloak.org\/docs-api\/8.0\/javadocs\/index.html\">https:\/\/www.keycloak.org\/docs-api\/8.0\/javadocs\/index.html<\/a><\/noindex><\/p>\n<h4>Enterprise-level identity providers (On-Premise)<\/h4>\n<p>\nAbility to authenticate users through User Federation services.<\/p>\n<p><img decoding=\"async\" alt=\"SSO on microservices architecture. Using Keycloak. Part #1\" src=\"\/wp-content\/uploads\/2020\/02\/59bbeaf4630855467ddb003d52b0c1b6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAlso allows for seamless authentication \u2013 if users authenticate on workstations with Kerberos (LDAP or AD), they can be automatically authenticated on Keycloak without needing to re-enter their username and password. <\/p>\n<p>For user authentication and subsequent authorization, a relational DBMS can be used, which is most applicable for development environments as it does not require lengthy setup and integration during the early stages of projects. By default, Keycloak uses an embedded DBMS for storing configurations and user data.<\/p>\n<p>The list of supported DBMS is extensive and includes: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle, and others. The most tested systems so far are Oracle 12C Release 1 RAC and Galera 3.12 cluster for MariaDB 10.1.19. <\/p>\n<h4>Identity providers \u2014 social login <\/h4>\n<p>\nIt is possible to use login from social networks. To activate the ability to authenticate users, the Keycloak admin console is used. No changes to application code are required, and this functionality is available \"out of the box\" and can be activated at any stage of project implementation.<\/p>\n<p><img decoding=\"async\" alt=\"SSO on microservices architecture. Using Keycloak. Part #1\" src=\"\/wp-content\/uploads\/2020\/02\/546ddea10c79662ca37a448d3dfc1fd0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUser authentication can use OpenID\/SAML Identity providers.<\/p>\n<h3>Typical authorization scenarios using OAuth2 in Keycloak<\/h3>\n<p>\n<b>Authorization Code Flow <\/b> \u2014 used with server-side applications. One of the most common types of authorization grants because it is well-suited for server-side applications where the application's source code and client data are not accessible to outsiders. The process in this case is built on redirection. The application must be able to interact with a user agent, such as a web browser \u2014 receiving authorization codes redirected through the user agent.<\/p>\n<p><b>Implicit Flow<\/b> \u2014 used by mobile or web applications (applications running on the user's device).<\/p>\n<p>The implicit authorization grant type is used by mobile and web applications where client confidentiality cannot be guaranteed. The implicit grant type also uses user-agent redirection, with the access token being passed to the user agent for further use within the application. This makes the token accessible to the user and other applications on the user's device. In this type of authorization grant, there is no authentication of the application\u2019s authenticity, and the process relies on the redirect URL (previously registered with the service).<\/p>\n<p>Implicit Flow does not support access token refresh tokens.<br \/>\n<br \/>\n<b>Client Credentials Grant Flow<\/b> \u2014 used when an application accesses the API. This type of authorization grant is typically used for \"server-to-server\" interactions that need to be performed in the background without immediate user interaction. The client credentials grant allows a web service (confidential client) to use its own credentials instead of user impersonation for authentication when calling another web service. For a higher level of security, the calling service may use a certificate (instead of a shared secret) as credentials.<\/p>\n<p>The OAuth2 specification is described in <br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/tools.ietf.org\/html\/rfc6749\">RFC-6749<\/a><\/noindex> <br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/tools.ietf.org\/html\/rfc8259\">RFC-8252<\/a><\/noindex> <br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/tools.ietf.org\/html\/rfc6819\">RFC-6819<\/a><\/noindex><\/p>\n<h3>JWT token and its benefits<\/h3>\n<p>\nJWT (JSON Web Token) is an open standard (<noindex><a rel=\"nofollow\" href=\"https:\/\/tools.ietf.org\/html\/rfc7519\">https:\/\/tools.ietf.org\/html\/rfc7519<\/a><\/noindex>), which defines a compact and self-contained way for securely transmitting information between parties as a JSON object.<\/p>\n<p>According to the standard, a token consists of three parts in base-64 format, separated by dots. The first part is called the header, which includes the type of token and the name of the hash algorithm used for generating the digital signature. The second part holds the main information (user, attributes, etc.). The third part is the digital signature.<\/p>\n<p>..<br \/>\nNever store the token in your database. Because a valid token is equivalent to a password, storing the token is like storing a password in plain text.<br \/>\n<b>Access token <\/b>is a token that provides its owner access to protected server resources. It usually has a short lifespan and can carry additional information, such as the IP address of the party requesting the token.<\/p>\n<p><b>Refresh Token <\/b>is a token that allows clients to request new access tokens after their expiration. These tokens are typically issued for a longer duration.<\/p>\n<p>Key benefits of using it in a microservices architecture:<\/p>\n<ul>\n<li>The ability to access various applications and services through a one-time authentication.<\/li>\n<li>If some required attributes are missing in user profiles, data enrichment can be done, which can include automated and 'on-the-fly' additions.<\/li>\n<li>There is no need to store information about active sessions; the server application only needs to verify the signature.<\/li>\n<li>More flexible access management through additional attributes in the payload.<\/li>\n<li>Using a token signature for the header and payload enhances the overall security of the solution.<\/li>\n<\/ul>\n<p><\/p>\n<h3>JWT token - composition<\/h3>\n<p>\n<b>The header<\/b> by default, the header contains only the type of token and the algorithm used for encryption.<\/p>\n<p>The type of token is stored in the 'typ' key. The 'typ' key is ignored in JWT. If the 'typ' key is present, its value must be JWT to indicate that this object is a JSON Web Token.<\/p>\n<p>The second key 'alg' defines the algorithm used for encrypting the token. By default, it should be set to HS256. The header is encoded in base64.<\/p>\n<p>{ \"alg\": \"HS256\", \"typ\": \"JWT\"}<br \/>\n<b>Payload (content)<\/b> stores any information that needs to be verified. Each key in the payload is known as a 'claim'. For example, an application may only allow entry by invitation (closed promo). When we want to invite someone to participate, we send them an invitation letter. It's important to verify that the email address belongs to the person accepting the invitation, so we will include this address in the payload by saving it under the 'email' key.<\/p>\n<p>{ \"email\": \"example@x5.ru\" }<br \/>\n<br \/>\nKeys in the payload can be arbitrary. However, there are several reserved ones:<\/p>\n<ul>\n<li>iss (Issuer) - identifies the application from which the token is sent.<\/li>\n<li>sub (Subject) \u2014 defines the subject of the token.<\/li>\n<li>aud (Audience) \u2013 an array of case-sensitive strings or URIs that serves as a list of recipients for this token. When the receiving party gets a JWT with this key, it must check for its presence in the recipients \u2014 otherwise, it should ignore the token.<\/li>\n<li>exp (Expiration Time) \u2014 specifies when the token expires. The JWT standard requires that tokens with expired validity be rejected in all implementations. The exp key must be a timestamp in Unix format.<\/li>\n<li>nbf (Not Before) \u2014 this time in Unix format defines when the token will become valid.<\/li>\n<li>iat (Issued At) \u2014 this key represents the time when the token was issued and can be used to determine the age of the JWT. The iat key must be a timestamp in Unix format.<\/li>\n<li>jti (JWT ID) \u2014 a string that defines a unique identifier for this token, case-sensitive.<\/li>\n<\/ul>\n<p>\nIt is important to understand that the payload is not transmitted in encrypted form (although tokens can be nested and thus allow the transmission of encrypted data). Therefore, it should not contain any secret information. Like the header, the payload is encoded in base64.<br \/>\n<b>Signature<\/b> \u2014 when we have a header and payload, we can compute the signature.<\/p>\n<p>The encoded base64: header and payload are combined into a string separated by a dot. Then this string and the secret key are fed into the encryption algorithm specified in the header (the \"alg\" key). The key can be any string. Longer strings are preferable, as they will take longer to crack.<\/p>\n<p>{\"alg\":\"RSA1_5\",\"payload\":\"A128CBC-HS256\"}<\/p>\n<h3>Building a fault-tolerant Keycloak cluster architecture<\/h3>\n<p>\nWhen using a single cluster for all projects, there are increased demands for the SSO solution. When the number of projects is small, these demands are not as noticeable across all projects; however, as the number of users and integrations increases, the requirements for availability and performance also rise. <\/p>\n<p>The increase in risks of a single SSO failure raises the requirements for the solution architecture and the methods of component redundancy used, leading to a very strict SLA. As a result, projects often have their own non-redundant infrastructure during the development or early stages of solution implementation. As the project develops, it is essential to incorporate opportunities for growth and scaling. The most flexible way to build a fault-tolerant cluster is through the use of container virtualization or a hybrid approach. <\/p>\n<p>To operate in Active\/Active and Active\/Passive cluster modes, data consistency in the relational database must be ensured\u2014both database nodes must be synchronized and replicated across various geographically distributed data centers.<\/p>\n<p>The simplest example of a fault-tolerant installation.<\/p>\n<p><img decoding=\"async\" alt=\"SSO on microservices architecture. Using Keycloak. Part #1\" src=\"\/wp-content\/uploads\/2020\/02\/c0df30a07e7dda5ae892a1fca3790a45.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWhat advantages does the use of a unified cluster provide:<\/p>\n<ul>\n<li>High availability and performance.<\/li>\n<li>Support for operation modes: Active\/Active, Active\/Passive.<\/li>\n<li>Dynamic scalability potential\u2014when using container virtualization.<\/li>\n<li>Centralized management and monitoring capabilities.<\/li>\n<li>A unified approach to user identification\/authentication\/authorization in projects.<\/li>\n<li>More transparent interaction between different projects without user involvement.<\/li>\n<li>The ability to reuse JWT tokens across different projects.<\/li>\n<li>A single point of trust.<\/li>\n<li>Faster project launches using microservices\/container virtualization (no need to set up and configure additional components).<\/li>\n<li>Possibility of obtaining commercial support from the vendor. <\/li>\n<\/ul>\n<p><\/p>\n<h3>What to pay attention to when planning a cluster.<\/h3>\n<p><\/p>\n<h4>DBMS<\/h4>\n<p>\nKeycloak uses a DBMS management system to store: realms, clients, users, etc.<br \/>\nA wide range of DBMS is supported: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak comes with its own built-in relational database, which is recommended for lightly loaded environments such as development environments.<\/p>\n<p>To operate in Active\/Active and Active\/Passive cluster modes, data consistency in the relational database must be ensured, and both nodes of the database cluster are synchronized and replicated across data centers.<\/p>\n<h4>Distributed cache (Infinispan)<\/h4>\n<p>\nFor the proper functioning of the cluster, additional synchronization of the following cache types is required using JBoss Data Grid:<\/p>\n<p>Authentication sessions \u2014 used to store data during the authentication of a specific user. Requests from this cache typically include only the browser and the Keycloak server, not the application.<\/p>\n<p>Action tokens \u2014 used for scenarios where the user needs to confirm an action asynchronously (via email). For example, during the forget password flow, the actionTokens cache in Infinispan is used to track metadata about related action markers that have already been used, so it cannot be reused.<\/p>\n<p>Caching and invalidation of persistent data \u2013 used for caching permanent data to avoid unnecessary database requests. When any Keycloak server updates data, all other Keycloak servers in all data centers must be informed.<\/p>\n<p>Work \u2014 used solely for sending invalidation messages between cluster nodes and data centers. <\/p>\n<p>User sessions \u2014 used to store data about user sessions that are valid during the user's browser session. The cache must handle HTTP requests from the end user and the application. <\/p>\n<p>Brute force protection \u2014 used to track data on failed login attempts. <\/p>\n<h4>Load balancing<\/h4>\n<p>\nThe load balancer is the single point of entry into Keycloak and must support sticky sessions. <\/p>\n<h4>Application servers<\/h4>\n<p>\nAre used to control the interaction between components and can be virtualized or containerized using available automation means and dynamic scaling of infrastructure automation tools. The most common deployment scenarios are in OpenShift, Kubernetes, Rancher.<\/p>\n<p>This concludes the first part \u2014 the theoretical one. In the upcoming series of articles, examples of integrations with various identity providers and configuration examples will be discussed.<br \/>\n<br \/>Source: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/X5RetailGroup\/blog\/486778\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u043b\u044e\u0431\u043e\u0439 \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u0438 X5 Retail Group \u043d\u0435 \u0438\u0441\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u0435, \u043f\u043e \u043c\u0435\u0440\u0435 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f \u0432\u043e\u0437\u0440\u0430\u0441\u0442\u0430\u0435\u0442 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0433\u0434\u0435 \u0442\u0440\u0435\u0431\u0443\u0435\u0442\u0441\u044f \u0430\u0432\u0442\u043e\u0440\u0438\u0437\u0430\u0446\u0438\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439. \u0421 \u0442\u0435\u0447\u0435\u043d\u0438\u0435\u043c \u0432\u0440\u0435\u043c\u0435\u043d\u0438 \u0442\u0440\u0435\u0431\u0443\u0435\u0442\u0441\u044f \u0431\u0435\u0441\u0448\u043e\u0432\u043d\u044b\u0439 \u043f\u0435\u0440\u0435\u0445\u043e\u0434 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439 \u0438\u0437 \u043e\u0434\u043d\u043e\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0432 \u0434\u0440\u0443\u0433\u043e\u0439 \u0438 \u0442\u043e\u0433\u0434\u0430 \u0432\u043e\u0437\u043d\u0438\u043a\u0430\u0435\u0442 \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e\u0441\u0442\u044c \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f \u0435\u0434\u0438\u043d\u043e\u0433\u043e \u0441\u0435\u0440\u0432\u0435\u0440\u0430 Single-Sing-On (SSO). \u041d\u043e \u043a\u0430\u043a \u0431\u044b\u0442\u044c, \u043a\u043e\u0433\u0434\u0430 \u0442\u0430\u043a\u0438\u0435 \u0438\u0434\u0435\u043d\u0442\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0435 \u043f\u0440\u043e\u0432\u0430\u0439\u0434\u0435\u0440\u044b \u043a\u0430\u043a AD \u0438\u043b\u0438 \u0438\u043d\u044b\u0435, \u043d\u0435 \u043e\u0431\u043b\u0430\u0434\u0430\u044e\u0449\u0438\u0435 \u0434\u043e\u043f\u043e\u043b\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u043c\u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":40866,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-40865","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u043b\u044e\u0431\u043e\u0439 \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u0438 X5 Retail Group \u043d\u0435 \u0438\u0441\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u0435, \u043f\u043e \u043c\u0435\u0440\u0435 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f \u0432\u043e\u0437\u0440\u0430\u0441\u0442\u0430\u0435\u0442 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0433\u0434\u0435 \u0442\u0440\u0435\u0431\u0443\u0435\u0442\u0441\u044f \u0430\u0432\u0442\u043e\u0440\u0438\u0437\u0430\u0446\u0438\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/en\/blog\/sso-na-mikroservisnoj-arhitekture-ispolzuem-keycloak-chast-%e2%84%961\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"en_US\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47SSO \u043d\u0430 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435. \u0418\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c Keycloak. \u0427\u0430\u0441\u0442\u044c \u21161 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412 \u043b\u044e\u0431\u043e\u0439 \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u0438 X5 Retail Group \u043d\u0435 \u0438\u0441\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u0435, \u043f\u043e \u043c\u0435\u0440\u0435 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f \u0432\u043e\u0437\u0440\u0430\u0441\u0442\u0430\u0435\u0442 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0433\u0434\u0435 \u0442\u0440\u0435\u0431\u0443\u0435\u0442\u0441\u044f \u0430\u0432\u0442\u043e\u0440\u0438\u0437\u0430\u0446\u0438\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/en\/blog\/sso-na-mikroservisnoj-arhitekture-ispolzuem-keycloak-chast-%e2%84%961\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-02-05T07:07:04+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-05T07:07:04+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47SSO in a Microservices Architecture. Using Keycloak. Part #1 | ProHoster","description":"In any large company, and X5 Retail Group is no exception, the number of projects requiring user authorization grows as it develops.","canonical_url":"https:\/\/prohoster.info\/en\/blog\/sso-na-mikroservisnoj-arhitekture-ispolzuem-keycloak-chast-%e2%84%961","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47SSO \u043d\u0430 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0435. \u0418\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c Keycloak. \u0427\u0430\u0441\u0442\u044c \u21161 | ProHoster","og:description":"\u0412 \u043b\u044e\u0431\u043e\u0439 \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u0438 X5 Retail Group \u043d\u0435 \u0438\u0441\u043a\u043b\u044e\u0447\u0435\u043d\u0438\u0435, \u043f\u043e \u043c\u0435\u0440\u0435 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u044f \u0432\u043e\u0437\u0440\u0430\u0441\u0442\u0430\u0435\u0442 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0433\u0434\u0435 \u0442\u0440\u0435\u0431\u0443\u0435\u0442\u0441\u044f \u0430\u0432\u0442\u043e\u0440\u0438\u0437\u0430\u0446\u0438\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439.","og:url":"https:\/\/prohoster.info\/en\/blog\/sso-na-mikroservisnoj-arhitekture-ispolzuem-keycloak-chast-%e2%84%961","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-02-05T07:07:04+00:00","article:modified_time":"2020-02-05T07:07:04+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"40865","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 10:46:14","updated":"2022-09-27 14:28:39","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/40865","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=40865"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/40865\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/40866"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=40865"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=40865"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=40865"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}