guoqqqi commented on code in PR #1518:
URL: https://github.com/apache/apisix-website/pull/1518#discussion_r1184644196


##########
blog/en/blog/2023/03/09/authenticate-openid-connect.md:
##########
@@ -0,0 +1,195 @@
+---
+title: Authenticate with OpenID Connect and Apache APISIX
+authors:
+  - name: Nicolas Fränkel
+    title: Author
+    url: https://github.com/nfrankel
+    image_url: https://avatars.githubusercontent.com/u/752258
+keywords:
+  - Authentication
+  - OAuth 2.0
+  - OpenID Connect
+  - Google Cloud
+description: >
+  Lots of companies are eager to provide their identity provider: Twitter, 
Facebook, Google, etc. For smaller businesses, not having to manage identities 
is a benefit. However, we want to avoid being locked into one provider. In this 
post, I want to demo how to use OpenID Connect using Google underneath and then 
switch to Azure.
+tags: [Ecosystem]
+image: 
https://blog.frankel.ch/assets/resources/authenticate-openid-connect/eye-gd82fef23c.jpg
+---
+
+>Lots of companies are eager to provide their identity provider: Twitter, 
Facebook, Google, etc. For smaller businesses, not having to manage identities 
is a benefit. However, we want to avoid being locked into one provider. In this 
post, I want to demo how to use OpenID Connect using Google underneath and then 
switch to Azure.
+
+<!--truncate-->
+
+<head>
+    <link rel="canonical" 
href="https://blog.frankel.ch/authenticate-openid-connect/"; />
+</head>
+
+## OpenID Connect
+
+The idea of an _authorization_ open standard started with 
[OAuth](https://en.wikipedia.org/wiki/OAuth) around 2006. Because of a security 
issue, OAuth 2.0 superseded the initial version. OAuth 2.0 became an <abbr 
title="Internet Engineering Task Force">IETF</abbr> <abbr title="Request For 
Comments">RFC</abbr> in 2012:
+
+>The OAuth 2.0 authorization framework enables a third-party
+>application to obtain limited access to an HTTP service, either on
+>behalf of a resource owner by orchestrating an approval interaction
+>between the resource owner and the HTTP service, or by allowing the
+>third-party application to obtain access on its own behalf
+>
+>-- [RFC 7469 - The OAuth 2.0 Authorization 
Framework](https://www.rfc-editor.org/rfc/rfc6749)
+
+OAuth focuses mostly on _authorization_;
+the _authentication_ part is pretty light:
+it contains a section about Client Password authentication and one Other 
Authentication Methods.
+
+>The authorization server MAY support any suitable HTTP authentication
+>scheme matching its security requirements.  When using other
+>authentication methods, the authorization server MUST define a
+>mapping between the client identifier (registration record) and
+>authentication scheme.
+>
+>-- [2.3.2.  Other Authentication 
Methods](https://www.rfc-editor.org/rfc/rfc6749#section-2.3.2)
+
+OpenID Connect uses OAuth 2.0 and adds the _authentication_ part:
+
+>OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 
protocol. It allows Clients to verify the identity of the End-User based on the 
authentication performed by an Authorization Server, as well as to obtain basic 
profile information about the End-User in an interoperable and REST-like manner.
+>
+>OpenID Connect allows clients of all types, including Web-based, mobile, and 
JavaScript clients, to request and receive information about authenticated 
sessions and end-users. The specification suite is extensible, allowing 
participants to use optional features such as encryption of identity data, 
discovery of OpenID Providers, and logout, when it makes sense for them.
+>
+>-- [What is OpenID Connect?](https://openid.net/connect/)
+
+Here are a couple of identity providers that are compatible with OpenID 
Connect:
+
+* GitHub
+* Google
+* Microsoft
+* Apple
+* Facebook
+* Twitter
+* Spotify
+
+In the following, we will start with Google and switch to Azure to validate 
our setup.
+
+## Setting up OpenID Connect with Apache APISIX
+
+Imagine we have a web app behind Apache APISIX that we want to secure with 
OpenID Connect. Here's the corresponding Docker Compose file:
+
+```yaml
+version: "3"
+
+services:
+  apisix:
+    image: apache/apisix:3.1.0-debian                              #1
+    ports:
+      - "9080:9080"
+    volumes:
+      - ./apisix/config.yml:/usr/local/apisix/conf/config.yaml:ro  #2
+      - ./apisix/apisix.yml:/usr/local/apisix/conf/apisix.yaml:ro  #3
+    env_file:
+      - .env
+  httpbin:
+    image: kennethreitz/httpbin                                    #4
+```
+
+1. Apache APISIX API Gateway
+2. APISIX configuration - used to configure it statically in the following line
+3. Configure the single route
+4. Webapp to protect. Any will do
+
+Apache APISIX offers a plugin-based architecture. One such plugin is the 
[openid-connect](https://apisix.apache.org/docs/apisix/plugins/openid-connect/) 
plugin, which allows using OpenID Connect.
+
+Let's configure it:
+
+```yaml
+routes:
+  - uri: /*                                                                    
#1
+    upstream:
+      nodes:
+        "httpbin:80": 1                                                        
#1
+    plugins:
+      openid-connect:
+        client_id: ${{OIDC_CLIENTID}}                                          
#2
+        client_secret: ${{OIDC_SECRET}}                                        
#2
+        discovery: https://${{OIDC_ISSUER}}/.well-known/openid-configuration   
#2-3
+        redirect_uri: http://localhost:9080/callback                           
#4
+        scope: openid                                                          
#5
+        session:
+          secret: ${{SESSION_SECRET}}                                          
#6
+#END
+```
+
+1. Catch-all route to the underlying web app
+2. Plugin configuration parameters. Values depend on the exact provider (see 
below)
+3. OpenID Connect can use a Discovery endpoint to get all necessary OAuth 
endpoints. See [OpenID Connect Discovery 1.0 
spec](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig)
 for more information
+4. Where to redirect when the authentication is successful. It mustn't clash 
with any of the explicitly defined routes. The plugin creates a dedicated route 
there to work its magic.
+5. Default scope
+6. Key to encrypt session data. Put whatever you want.

Review Comment:
   When the secret is too short, the following error log will appear. Do we 
need to specify here that the key length is at least 16?
   ```
   err:failed to check the configuration of plugin openid-connect err: property 
"session" validation failed: property "secret" validation failed: string too 
short, expected at least 16, got 4 
   ```



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to