简体   繁体   English

使用Amazon Cognito的授权代码授予无服务器/单页Web应用程序

[英]Using Amazon Cognito's Authorization Code Grant with Serverless/Single-Page Web Application

I'm attempting to develop a serverless JavaScript web application consisting of API Gateway (w/ an Amazon Cognito Custom Authorizer), Lambda, and DynamoDB. 我正在尝试开发一个无服务器的JavaScript Web应用程序,包括API Gateway(带有Amazon Cognito自定义授权程序),Lambda和DynamoDB。 This post is my last attempt to make Cognito work for my needs before completely giving up on it (for a 2nd time). 这篇文章是我最后一次尝试让Cognito在完全放弃之前(第二次)满足我的需求。 I'll try to infuse a bit what I've learned since the Cognito documentation is confusing and lacking. 我会尝试注入一些我所学到的知识,因为Cognito文档令人困惑和缺乏。

With Cognito, you can develop a custom authentication workflow with your own registration, sign in, etc. web pages. 使用Cognito,您可以使用自己的注册,登录等网页开发自定义身份验证工作流程。 You also have the option to leverage Amazon's Hosted Web UI to make things a bit simpler (although with very few HTML/CSS customization options). 您还可以选择利用亚马逊的托管Web UI使事情变得更简单(尽管HTML / CSS自定义选项很少)。 I'm using the latter. 我正在使用后者。

When configuring an App Client for a Cognito User Pool, the most critical decision you have to make is whether to use an Authorization Code Grant or an Implicit Grant. 为Cognito用户池配置App Client时,您必须做出的最关键决定是使用授权代码授予还是使用隐式授权。 With an Authorization Code Grant, a successful authentication will return a session token containing a JWT id_token, access_token, and refresh_token to your caller. 使用授权代码授予,成功的身份验证将向您的调用者返回包含JWT id_token,access_token和refresh_token的会话令牌。 With an Implicit Grant, your caller will receive an Authorization code that can be used to obtain an id_token and an access_token only, with no refresh_token. 使用隐式授权,您的调用者将收到一个授权代码,该代码可用于获取id_token和access_token,而不使用refresh_token。 The Implicit Grant is most suitable for serverless (or single-page) applications because it won't expose a long-lived refresh_token to the client which can be easily compromised and used to assume valid access to your application. 隐式授权最适合无服务器(或单页)应用程序,因为它不会向客户端公开长期存在的refresh_token,这很容易被破坏并用于假定对应用程序的有效访问。 However, the access_token has a fixed expiration of one hour that cannot be configured at this time. 但是,access_token具有一小时的固定到期时间,此时无法配置。 So, without a refresh token to silently renew the access_token, your user will have to log-in every hour. 因此,如果没有刷新令牌来静默更新access_token,则您的用户必须每小时登录一次。

Since my web application in no way contains sensitive information, I'm going to use the Authorization Code Grant and persist the tokens in the browser's LocalStorage ( which is unsafe, not recommended, and a bad practice ) in hopes that, at some point, Cognito will fully comply with the OpenId Spec and provide full support for refresh tokens with implicit grants via prompt=none . 由于我的Web应用程序绝不包含敏感信息,因此我将使用授权代码授权并在浏览器的LocalStorage中保留令牌( 这是不安全的,不推荐的,也是一种不好的做法 ),希望在某些时候, Cognito将完全符合OpenId规范,并通过prompt = none提供对隐式授权的刷新令牌的完全支持。 As you can see, Amazon has been unresponsive on the matter. 如您所见,亚马逊在此事上一直没有反应。 Heck, even an option to customize the expiration time of the access_token (with Implicit grant) would be a nice compromise. 哎呀,即使是自定义access_token的到期时间(使用隐式授权)的选项也是一个很好的折衷方案。

So I've successfully deployed the sample application from the amazon-cognito-auth-js JavaScript library, which is meant to be used with the Hosted Web UI flow. 所以我已成功部署了amazon-cognito-auth-js JavaScript库中的示例应用程序,该库旨在与Hosted Web UI流程一起使用。 This should not be confused with the amazon-cognito-identity-js library, which should be used if you're developing your own custom authentication workflow. 这不应该与amazon-cognito-identity-js库混淆,如果您正在开发自己的自定义身份验证工作流程,则应该使用它。 The amazon-cognito-auth-js library supports both the Authorization Code Grant as well as the Implicit Grant and will handle parsing the tokens, caching/retrieving them to/from LocalStorage, and silently renewing the access_token with the refresh token (for Authorization Code Grant). amazon-cognito-auth-js库既支持授权代码授权,也支持隐式授权,并将处理解析令牌,缓存/从LocalStorage检索它们,以及使用刷新令牌静默更新access_token(对于授权码)格兰特)。

When I sign-in, my browser URL resembles the following: https://www.myapp.com/home?code=ABC123XYZ ... and the three JWT tokens are set in the browser's LocalStorage. 当我登录时,我的浏览器URL类似于以下内容: https ://www.myapp.com/home?code = ABC123XYZ ...并且三个JWT令牌在浏览器的LocalStorage中设置。 If I immediately refresh the page, however, I receive an "invalid_grant" error, because the Authorization code is still in the URL and has already been consumed. 但是,如果我立即刷新页面,则会收到“invalid_grant”错误,因为授权代码仍在URL中并且已被使用。 Should I just do a page redirect upon successful sign-in to remove the Authorization code from the URL? 我是否应该在成功登录后执行页面重定向以从URL中删除授权代码? Here's the main code at play which I plan to call fromthe onLoad() of every page in my app: 这是我打算从我的应用程序中每个页面的onLoad()调用的主要代码:

function initCognitoSDK() {
        var authData = {
            ClientId : '<TODO: your app client ID here>', // Your client id here
            AppWebDomain : '<TODO: your app web domain here>', // Exclude the "https://" part. 
            TokenScopesArray : <TODO: your scope array here>, // like ['openid','email','phone']...
            RedirectUriSignIn : '<TODO: your redirect url when signed in here>',
            RedirectUriSignOut : '<TODO: your redirect url when signed out here>',
            IdentityProvider : '<TODO: your identity provider you want to specify here>', 
                    UserPoolId : '<TODO: your user pool id here>', 
                    AdvancedSecurityDataCollectionFlag : <TODO: boolean value indicating whether you want to enable advanced security data collection>
        };
        var auth = new AmazonCognitoIdentity.CognitoAuth(authData);
        // You can also set state parameter 
        // auth.setState(<state parameter>);  
        auth.userhandler = {
            onSuccess: function(result) {
                alert("Sign in success");
                showSignedIn(result);
            },
            onFailure: function(err) {
                alert("Error!" + err);
            }
        };
        // The default response_type is "token", uncomment the next line will make it be "code".
        auth.useCodeGrantFlow();
        return auth;
    }

如果您的应用程序可以在浏览器本地存储中找到有效的访问令牌,则可以重定向以从查询字符串中删除代码或检查页面加载,在这种情况下,忽略查询字符串中收到的代码。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 单页JavaScript Web应用程序的体系结构? - Architecture of a single-page JavaScript web application? 链接单页Web应用程序的各个部分 - Linking parts of a single-page web application 单页应用程序和网页标题 - Single-page application and web-page title 在单页pushState Web应用程序中模拟画外音页面加载 - Simulate Voiceover page load in single-page pushState web application 在单页网页设计上实现链接 - Implement links on single-page web design 具有实际URL的单页应用程序 - Single-Page Application with Real URLs 单页Web应用程序是否应该与服务器保持一个Web Socket连接? - Should a single-page web application keep one Web Socket connection to the server or several? 如果未从根目录访问单页​​Web应用程序(SPA),则保证HTML信息 - Guaranteed HTML information if single-page web application (SPA) is not accessed at the root 使用Javascript / jQuery AJAX的ASP.NET MVC 3单页面应用程序:内存和分离的DOM问题 - ASP.NET MVC 3 Single-Page Application using Javascript/jQuery AJAX: Memory and Detached DOM Issues 单页网页应用中的Google Analytics跟踪问题 - Google Analytics trackevent in single-page web app
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM