【问题标题】:.Net Core API Google authentication JWT create or reuse google token?.Net Core API Google 身份验证 JWT 创建或重用谷歌令牌?
【发布时间】:2020-10-25 05:05:56
【问题描述】:

您好,我想让用户使用 Google 进行身份验证,我想要我的 API 并使用他们的 Google 令牌代表他们与 google 进行通信。 这是到目前为止的图表。这 ????是我想知道我应该返回客户的地方。

a) 我应该返回自己的 JWT 并使用它来验证所有其他客户端请求吗?但是为了代表他们与谷歌沟通,我必须存储他们不想存储的令牌

b) 我应该将 google 令牌返回给客户端,以便他们使用它来验证他们的请求吗?我是否有一个开箱即用的中间件来再次使用谷歌验证他们的令牌?还是我自己写一个?

c) 其他选项?

基本上我需要他们的谷歌令牌,这样我就可以与谷歌 API 交谈,但我不想将其存储,我也不希望客户需要发送我的 JWT 和他们的谷歌令牌与每个请求。

编辑 这是我的自定义 google 令牌验证器,但这只是客户端通过请求发送 google 令牌时的验证。

    public class CustomGoogleTokenValidator : ISecurityTokenValidator
{
    private readonly JwtSecurityTokenHandler tokenHandler;
    private readonly ILogger logger;

    public bool CanValidateToken => true;

    public int MaximumTokenSizeInBytes { get; set; } = TokenValidationParameters.DefaultMaximumTokenSizeInBytes;

    public CustomGoogleTokenValidator(ILogger logger)
    {
        tokenHandler = new JwtSecurityTokenHandler();
        this.logger = logger ?? throw new ArgumentNullException(nameof(logger));
    }
    public bool CanReadToken(string securityToken)
    {
        return tokenHandler.CanReadToken(securityToken);
    }

    public ClaimsPrincipal ValidateToken(string securityToken, TokenValidationParameters validationParameters, out SecurityToken validatedToken)
    {
        validatedToken = null;


        var payload = GoogleJsonWebSignature.ValidateAsync(securityToken, new GoogleJsonWebSignature.ValidationSettings()).Result;

        // TODO VALIDATE
        //payload.Audience == "myclientid";
        //payload.Issuer == "accounts.google.com" or "https://accounts.google.com"
        //payload.ExpirationTimeSeconds > 0;

        var claims = new List<Claim>
            {
                new Claim(ClaimTypes.NameIdentifier, payload.Name),
                new Claim(ClaimTypes.Name, payload.Name),
                new Claim(JwtRegisteredClaimNames.FamilyName, payload.FamilyName),
                new Claim(JwtRegisteredClaimNames.GivenName, payload.GivenName),
                new Claim(JwtRegisteredClaimNames.Email, payload.Email),
                new Claim(JwtRegisteredClaimNames.Sub, payload.Subject),
                new Claim(JwtRegisteredClaimNames.Iss, payload.Issuer),
            };

        try
        {
            var principle = new ClaimsPrincipal();
            principle.AddIdentity(new ClaimsIdentity(claims));
            return principle;
        }
        catch (Exception e)
        {
            this.logger.Error(e, "Error while creating claims priciple.");
            throw;
        }
    }
}

我仍然不知道在我登录验证后向他们发送谷歌令牌是否合适和足够。如下所示,还是我应该创建一个带有声明或其他内容的新 jwt?

  [AllowAnonymous]
    [HttpPost("google")]
    public async Task<IActionResult> Google([FromBody]GoogleLoginDto loginDto)
    {
        try
        {
            var payload = await GoogleJsonWebSignature.ValidateAsync(loginDto.TokenId, new GoogleJsonWebSignature.ValidationSettings());

            // TODO Check if user exists if not create new one...
            var user = this.GetUsers().FirstOrDefault(u => u.Email == payload.Email);         

            return Ok(new
            {
                token = loginDto.TokenId
            });
        }
        catch (Exception ex)
        {
            BadRequest(ex.Message);
        }
        return BadRequest();
    }

【问题讨论】:

    标签: oauth-2.0 asp.net-core-webapi google-authentication asp.net-core-3.1


    【解决方案1】:

    在 oauth 中,有 clientresource ownerauthorization serverresource server 等服务器角色。该资源应受到保护并授予授权,如下图所示:

    但是,据我所知,Google 不支持保护客户的资源,例如 Web API。您可以参考下面介绍的场景(OAuth 2.0 Overview)。大多数场景是关于如何实现 OAuth 2.0 授权以访问 Google API(资源)。看来您的场景更喜欢on-behalf-flow。您可以检查 service account 的 OAuth 2.0 是否适合您的场景。

    从技术上讲,如果您信任 Google 的授权服务器,则可以将令牌验证为您帖子中的代码。但是在这种情况下,您应该先验证签名(JWT 令牌),确保令牌是从 Google 发出的,然后再验证声明。这是一个关于验证AAD token的帖子,我已经回答了,你可以参考。

    要了解有关 OAuth 2.0 授权框架的概念,您可以参考rfc6749。而对于个人身份平台是否支持 OAuth,您需要在每个平台(Microsoft、Google 等)上进行检查。

    【讨论】:

      猜你喜欢
      • 2021-06-27
      • 2019-02-22
      • 2020-06-12
      • 2021-12-17
      • 2020-04-04
      • 2020-02-05
      • 2022-01-27
      • 2022-01-06
      • 1970-01-01
      相关资源
      最近更新 更多