30 分钟内即可使用 AWS Lambda 和 Supabase 实现 Google Auth
由 Mux 主办的 DEV 全球展示挑战赛:展示你的项目!
Google 身份验证很难实现……
如今,使用谷歌和其他服务提供商进行身份验证已十分普遍。然而,实施这些身份验证可能非常耗时,尤其是在涉及多个服务提供商时。😫
我使用 Supabase 在我的项目中通过 AWS Lambda 实现了 Google Auth,整个过程不到 30 分钟。方法如下👇🏼
如何配置 Supabase 🏁
Supabase 入门非常简单。以下是具体步骤:
- 注册:首先在 Supabase 平台上创建一个账户。注册过程简单易懂。📝
- 获取您的账户 URL 和令牌:注册成功后,请务必获取您的账户 URL 和令牌。这些凭证对于将 Supabase 与 AWS Lambda 身份验证集成至关重要。🔑
- 在 Supabase 中启用 Google 身份验证: Supabase 文档🌐
现在您已经拥有了 Supabase 凭据,让我们开始将您的前端连接到 Google 🚀
在您的登录页面添加 Google 按钮
使用 Supabase 非常简单。您只需安装@supabase/supabase-js并按照以下步骤操作即可。
-
创建 Supabase 客户端:
import { createClient } from "@supabase/supabase-js"; export const supabaseClient = createClient( "<https://xxxxx.supabase.co>", anon_key ); -
处理“使用 Google 登录”按钮的点击事件:
<button onClick={() => supabaseClient.auth.signInWithOAuth({ provider: 'google', })} >Login with Google</button>
用户将被重定向到 Google 身份验证页面,身份验证成功后,他们将带着令牌返回您的网站。🌐🔐
在所有后端调用中,都应该通过请求头包含此令牌。🚧
在您的后端处理 Supabase 令牌
-
创建Lambda 授权器:
当向 AWS Lambda 函数发出请求时,通常会经过 API 网关。在本例中,我会在 API 网关层拦截传入的请求,并通过自定义授权器手动验证请求中包含的令牌。
自定义授权器也是一个 Lambda 函数,它会在它所保护的路由执行之前运行。我需要创建一个新的 Lambda 函数,例如命名
customAuthorizer为 `authorizer_name`。以下代码片段演示了我如何从授权器中的令牌中提取用户 ID:
// I assume here that you've retrieved your secret key `SECRET` from Supabase // I also suppose that accessToken is formatted as `Bearer xxxxxxxxxx` export const getUserIdFromToken = (accessToken: string | undefined): string => { if (accessToken === undefined) { throw new Error('Missing token'); } const token = accessToken.split(' ')[1]; if (token === undefined) { throw a Error('Badly formatted token'); } try { const decoded = jwt.verify(token, SECRET); if (typeof decoded === 'string') { // you need to throw if the user in unauthorized throw new Error('Decoded token should not be a string'); } if (decoded.sub === undefined) { throw new Error('Cannot find sub'); } return decoded.sub; } catch (error) { throw new Error('Invalid token ' + JSON.stringify(error)); } };我在 API Gateway 配置中将自定义授权器函数声明为授权器。例如,使用 Serverless Framework 的代码如下所示:
httpApi: { ..., authorizers: { customAuthorizer: { type: 'request', functionName: 'customAuthorizer', // the name of my authorizer lambda }, }, } -
使用此新授权器作为我的 API 路由的路由保护器
export const chatCompletion = { environment: {}, handler: __dirname + '/handler.ts', // The path of the handler events: [ { httpApi: { method: 'post', path: '/chat/completion', authorizer: { name: 'customAuthorizer' }, // the authoriser i just created }, }, ], };
我们完成了!!!🥳
如果你想深入了解自定义授权器,请查看 AWS 提供的这篇非常棒的文档:AWS Lambda Authorizers with a Third-Party Identity Provider 👀
注意⚠️🔐
当使用 Supabase 的自定义授权器时,我们需要使用 Supabase密钥,该密钥应妥善存储在安全的位置,例如AWS Secret Manager。
AWS Cognito 与 Supabase:快速对比
在选择 Amazon Cognito 还是 Supabase 作为身份验证工具时,需要考虑以下几点:
| 标准 | 认知 | 苏帕巴 | 评论 |
|---|---|---|---|
| 每月10万用户的成本 | 550美元 | 325美元 | Supabase价格较低,因此成为一种经济实惠的选择,可以帮您省钱。💰 |
| 延迟 | 低的 | 高的 | Supabase 由于采用了自定义授权器,引入了一种新的 Lambda 执行方式,这可能会导致更高的延迟,因此对于低延迟应用来说,Cognito 是更佳选择。⏳ |
| 提供商集成 | 需要更多设置 | 精简,支持多个提供商 | Supabase简化了供应商集成流程,使其成为一个便捷的选择,尤其适合需要与多个供应商合作的用户。🚀 |
| 基础设施即代码 | 是的 | 不 | Cognito 支持基础设施即代码 (IAC),从而实现更自动化、可扩展的部署,使其在这方面具有优势。🛠️ |
| 无服务器集成 | 无缝的 | 无缝的 | 这两个平台都与无服务器架构集成良好,因此具体选择取决于项目中的其他因素。🤖 |
| 开发者社区 | 大的 | 生长 | Cognito拥有完善的社区,能够提供强大的支持和资源,使其成为一个极具吸引力的选择。👥 |
| 可扩展性 | 出色的 | 出色的 | 这两个平台在可扩展性方面都表现出色,因此您的决定可能取决于其他因素,例如成本或易用性。📈 |
| 遵守 | 强有力的合规框架 | 不断发展的合规功能 | Cognito 提供成熟的合规框架,如果您需要为项目建立强大的合规基础,那么 Cognito 是更好的选择。📜 |
| 用户体验 | 功能丰富但更复杂 | 简单明了 | Supabase 提供更友好的用户体验,如果您最看重的是简洁性和易用性,那么它就是您的理想之选。😄 |
| 性能考量 | 由于 AWS 服务集成良好,延迟通常较低。 | 自定义授权器和密钥检索可能会导致更高的延迟。 | 性能优化包括减少 Lambda 函数调用次数、利用 JWT 确保可扩展性,以及实施缓存以缩短响应时间并降低负载。⚙️📈🚀 |
探索其他方案:
虽然我重点介绍了 Supabase,但了解其他能与 AWS Lambda 无缝集成的身份验证服务也至关重要。不妨考虑一下 Clerk、Auth0 和 Firebase 等替代方案,找到最符合您项目需求的方案。🕵️♂️🔍🌟
文章来源:https://dev.to/slsbytheodo/implement-google-auth-with-aws-lambda-and-supabase-in-30-minutes-p15

