 Hi. I will begin this presentation. I'm Shitokai, from Hitachi. I'm happy to have this opportunity to speak here. Today, I would like to talk about a guide of authentication and authorization for cloud native applications with key clock. First of all, I will introduce myself. I'm Shitokai, and I'm a software engineer at Hitachi. And I'm a specialist in authentication and authorization. And I engage in authentication and authorization technical support. Also, I am a contributor of key clock, which is identity and access management OSS. I contribute to key clock, such as OS 2.0 device authorization grant, performance improvement, security improvement for tokens. In addition, I am a writer of web analytics about IAM. I return the main topic, the contents as follows. First, I will explain importance of authentication and authorization. Then I introduce key clock. In addition, I introduce authentication for cloud native applications with key clock. Finally, I introduce authorization for cloud native applications with key clock. First, I explain importance of authentication and authorization. First, I will explain what authentication and authorization are. First, authentication. Authentication is the process of verifying the user or client who or which is requesting API. As shown in the figure, before authentication, the system does not who the user is. However, once authenticated, the system knows who the user is. Second, authorization. Authorization is the process of verifying if user can access the request API. As shown in the figure, before authorization, the system does not know whether the user can access the API. However, authorized, the system knows whether the user can access the API. I experience security risk about authentication and authorization. Two security risks are listed in OSP top 10 API security. Two security risks are listed in OSP top 10 about authentication and authorization. Number one, broken access control. Number seven, identification, authentication, file loss. Moreover, four security risks are listed in OSP top 10 API security about authentication and authorization. Number one, broken object level authorization. Number two, broken authentication. Number three, broken object property level authorization. Number five, broken function level authorization. In this way, if you do not implement appropriate authentication and authorization, it leads to serious security risk. Therefore, it is important to minimize security risks by implementing appropriate authentication and authorization. Next, I introduce key clock. Key clock is IAM OSS. And here, I introduce three major features. The first feature is to support standard specification, such as OS 2.0, OpenID Connect 1.0, and SAML 2.0. The second is logging with social media, such as GitHub and Facebook and so on. I will explain this feature in detail later. The third feature is to connect to existing user stores, such as LDAP and Active Directory. In addition, key clock has two advantage for cloud-native environments. The first advantage is easy deployment on Kubernetes environment. There are two ways to deploy key clock in Kubernetes. And the first is using Docker image. The second is using key clock operator. The second advantage is that key clock is suitable for container environment. Key clock changes base distribution from wildfire to caucus in November 2022. Then key clock starting has been fast from 30.5 seconds to 8.7 seconds. And memory consumption of key clock at the starting has been less from 407 megabytes to 234 megabytes. Therefore, quick scaling is possible for key clock. From these two advantages, key clock is suitable for cloud-native environments. One more important thing is that in April 2023, key clock joins C&C as an incubating project. Key clock will be the standard IAM product for C&C ecosystem. I actually have to minimize security risks. And that's, I explained in previous slides. There are two important things to implement authorization and authorization, and to minimize security risks. First is supporting standard specification, recommended by best current practice, to protect from current attack methods. Second is continuing to support specifications recommended by new BCP to protect from new evolved attack methods. This is because, as shown in the figure, attack methods evolve day by day. And without supporting BCP, it becomes difficult to prevent attacks. Key clock satisfies above two important things. I will explain how key clock satisfies above two important things. First, I explained how key clock satisfies the first important things, that is, supporting standard specifications recommended by BCP to protect from current attack methods. Key clock has a following standard specification. As shown in the figure, key clock supports standard specification contained in BCP. Therefore, key clock satisfies the first important thing. Then I explained how key clock satisfies the second important things, and continuing to support standard specification recommended by new BCP to protect from new evolved attack methods. Key clock is quick to support standard specification. And this is because key clock has OSSIG, which implements security standard specification related to OSS or OpenID foundation. Currently, specialists of OSSIG discuss implementing standard specifications once a month. Also, the number of OSSIG GitHub for one year is 3011, and key clock ranked in seventh in terms of the first growing contributes current. Therefore, it is expected that community-increased OSSIG will continue to be active. So far, I hope you understand that key clock can implement security risks about authentication and authorization, and key clock suitable implementation for authentication and authorization in cloud-native environments. From here, I will introduce authentication and authorization for cloud-native application with key clock. First, I will introduce authentication for cloud-native application with key clock. The following functions are used in terms of authentication for cloud-native applications. In this presentation, I will explain single sign-on, social loggy, multi-factor authentication, and web awesome, and pass keys. Part of five authentication functions, the first function is single sign-on. Single sign-on is a system that allows you to use multi-application with one login. Key clock enables SSO by cookie authentication. Therefore, users do not have to import and manage user name and password for each application. The figure on the left illustrates the scenario when single sign-on is not enabled. In the left figure, a user must access login screen of each cloud-native application. The figure on the left illustrates the scenario when single sign-on is enabled with key clock. In the left figure, key clock provides same login experience in each cloud-native application. From the above, key clock improves user experience. Out of five authentication functions, the second function is social login. Social login is logged in service with account of social media. Key clock allows user to use account of social media such as Facebook, Twitter, and Microsoft, and so on. Therefore, users do not have to import user information, such as name, address, email, telephone, telephone number, and password. On the other hand, users do not have to register user information. In addition, users do not have to manage user name and password. The figure on the right illustrates the scenario when user use account of GitHub or Facebook to log in in cloud-native application with key clock. When user press login with GitHub, user access the GitHub login screen, then user can log in with user's GitHub account. The same applies when log in with account of Facebook. Therefore, user can cloud-native application without registering user information. From the above, key clock enhance user experience. Part of five authentication functions, the third function is multi-factor authentication. Multi-factor authentication is authenticating by using two or more of the following three. First is something you'd know, for example, password. Second is something you have, for example, authenticator. Third is something you are, for example, fingerprint. Key clock authenticates using something you know and something you have. The figure on the right illustrates the scenario when user log in using password and one-time password with key clock. First, user register authenticator with key clock. User access login screen and inputs user name and password. This is authenticated by something you know. When password authentication is successful, key clock return one-time password screen. User input one-time password displayed in Google Authenticator. This is authenticated by something you have. When one-time password authentication is successful, user can log in. Key clock prevents illegal authentication even if attacks succeed in password authentication by attack method, such as directionary attack, password-based attack, breadth-force attack, and reverse breadth-force attack. The figure on the right illustrates the scenario that the attacker knows victim's user name and password. Password authentication succeeds because attacker knows user name and password. After password authentication, attacker needs to perform one-time password authentication. But one-time password authentication fires because attacker does not have authenticator. In this way, key clock prevents illegal login with MFA. Out of five authentication functions, the fourth function is WebOSN. WebOSN is authentication technology which enables password-less authentication and MFA. Key clock authenticates user without password. Therefore, user do not need to remember complex password. Here, I will explain how key clock authenticates without password. First, user sends authentication request to key clock. And key clock returns challenge add to user. Then, user authenticates with authenticator. For example, fingerprint authentication, facial authentication. Here, I use fingerprint authentication. When fingerprint authentication is successful, authenticator signs challenge. And also get a pass signature for challenge to key clock. Key clock authenticates by referring to the signature. This is authentication by something you have. When verification of signature is successful, user can log in. Also, phishing can prevent in key clock. The figure in the board illustrates the scenario attacker use phishing site. First, attacker use user to phishing site. And the authenticator signs challenge. Second, authenticator pass signature for challenge to attacker. Third, attacker sends authentication request to key clock. And key clock returns challenge to attacker. Fourth, attacker sends signature obtained at second to key clock. And key clock verifies signature, but signature verification fails. Because the third challenge and fourth challenge are different. In this way, key clock provides secure authentication to user. Out of five functions, the fifth function is pass key. Pass key is authentication technology with synchronized credentials between multi-authenticators by cloud platform. Key clock authenticates user with multi-authenticators. Therefore, users can use smartphones and PCs as authenticator. The figure on the barrel illustrates the scenario when user use pass key with key clock. When user lost or replace smartphones, user can use PC or new smartphone as authenticator without registration. This is because credentials are synchronized. Key clock improves user experience. In Chapter 3, I introduced authentication for cloud native applications with key clock. I hope you understand that key clock provides basic advanced authentication functions. Finally, I will introduce authorization for cloud native application with key clock. To support the following standard specification is useful in terms of authorization for cloud native application. I will explain OS 2.0 financial-grade API 1.0, OS 2.0 device authorization ground. Out of three standard specifications, the first standard specification is OS 2.0. OS 2.0 is the default standard about issue of token, which is essential for authorization. Key clock issues token incomprehens with OS 2.0. The figure on the barrel illustrates the flow of OS 2.0. First, user use client. Client sends authorization requests to key clock via the browser. Second, key clock is user authentication and authorization. Third, key clock return authorization response to client via the browser. Fourth, client sends token request to key clock because client obtain access token. Access token is necessary to send API request. Fifth, key clock return token response includes access token. Seventh, client sends API request with access token. Seventh, the access service verifies access token and returns API response. This is the flow of OS 2.0. However, OS 2.0 is a standard specification with a high degree of freedom. So, there is an issue that it is easy to create security holes. In fact, there are attacks that cannot be prevented in OS 2.0. Out of three standard specifications, the second standard specification is the financial grade API. FAPI 1.0 is high-level security specification describing security, secure usage of OS 2.0 and OpenID Connect 1.0. For example, Pixi is optional in OS 2.0, but Pixi is required in FAPI 1.0 to increase security. I will explain the demand for FAPI 1.0. FAPI 1.0 is expected to support it, particular in the financial industry. The following is Open Banking is using FAPI 1.0. It's the first Open Banking in the UK. Second, consumer data rights in Australia. Third, Open Banking Brazil in Brazil. Fourth, SA may open banking in Saudi Arabia. In this way, FAPI 1.0 is attracting attention globally. Key clock prevents attacks that cannot be prevented in OS 2.0. Therefore, a user can use service security. First, I will explain attacks that cannot be prevented in OS 2.0. The figure in the below illustrates these attacks that cannot be prevented in OS 2.0. First, tempering of authorization requests. Authorization requests are easily tempered in OS 2.0 because authorization requests are sent up to your brother. Second is tempering of authorization response. Authorization response are easily tempered in OS 2.0 because authorization response are sent up to your brother. Authorization response is set and illegal use of API by stealing access token. There is no verification of... There is no verification of source of API request in OS 2.0. Therefore, if attacker steals access token, attacker illegally use API. I will explain how key clock prevents those three attacks that explained at previous slide. First is how to prevent tempering of authorization request. First, key clock requires client to sign authorization request. Therefore, if authorization request is tempered, key clock detects temper by verifying the signature. Second is authorization response. Second is how to prevent tempering of authorization response. Key clock signs authorization response. Therefore, if authorization response is tempered, client detects tempering by verifying the signature. Third is how to prevent illegal use of API by stealing access token. Key clock includes information of client certification in access token. Therefore, if attacker sends API request with access token, access service can reject API request. Because access service can note the right source of API request from information of client certification in access token. In this way, key clock provides us secure authorization to users. Out of three standard specifications, the third standard specification in O2.0 device authorization grant. O2.0 device authorization grant is designed for IoT device that is a rack or a browser or an input constraint text. Key clock executes authorization, even if client does not have browser. Therefore, users can use IoT device as client. The figure on the below illustrates the flow of O2.0 device authorization grant with key clock, when users use smart TV as client. First, client uses smart TV as client. And client sends device authorization request to key clock. And second, key clock return device authorization response with verification URI and user code. And client displays verification URI and user code. Third, user impets verification URI into smartphone and access verification URI. For a user is impetting URI, client continues to send token requests to key clock at all regular intervals. Key clock return token response to client. But user has not yet been authenticated and authorized. Token response does not include access token. And fourth, user access verification URI with smartphone and user executes user and user code authentication and authorization. And fifth, after authentication and authorization are complete, client sends token request to key clock. Six, key clock returns token response, include access token to client. Seventh, client sends API request with access token to access service. Eight, access service return API response to client. In this way, key clock use IoT device as clients. Since the number of IT device is likely to increase in the future, supporting O2.0 device authorization grants will be important. In chapter four, I introduce authorization for cloud native applications with key clock. I hope you have understood key clock supports various standard specifications. I will summarize this presentation. First, I explain importance of authentication and authorization. Next, I introduce key clock. Key clock joins CNCF as incubating project. So, key clock will be the default standard of IAM product for CNCF ecosystem. Next, I introduce authentication and authorization for cloud native application with key clock. For authorization, authentication, single sign-on, social login, multi-factor authentication, web authentication, and pass keys. For authorization, O2.0, API 1.0, O2.0 device authorization grants. In this way, key clock supports wide range of authentication features and authorization features. Finally, if you would like to know more about key clock, please see official document and GitHub and back written by the key clock project leader. Thank you for your attention. If there are any questions, I'd be pleased to answer them. Client has not monitored. In this, key clock has not... key clock executes... key clock do not executes authentication and authorization. Require monitor. Sorry, I could repeat that one, sorry. Key clock, good job. So, I must share.