2017-10-01 12 views
0

auth0サービスでカスタム認証者を使用してAPIゲートウェイを保護するのに数日間かかります。私は自分のベアラトークンを検証するラムダを持っています.LambdaはAWSコンソール内で呼び出すと動作します。カスタムオーソライザを作成すると、ベアラトークンで正常にテストできます。APIゲートウェイでカスタム承認者を使用できません

APIゲートウェイメソッドにオーソライザを接続し、auth0によって提供されたpostmanとトークンでリクエストをテストしようとすると、常に401ステータスコードが返されます。私はCloudWatchのログを読んで、HTTPリクエストを送信するたびに決して起動しない承認Lambdaを読んでいます。 https://auth0.com/docs/integrations/aws-api-gateway/custom-authorizers/

をそして、これは私の認証ラムダコードです:私はこのチュートリアルを、以下のい

ハンドラ:

'use strict'; 

let jwtManager = require("./jwt_manager"); 

module.exports.authenticate = (event, context, callback) => { 

    jwtManager.validate(event, function (error, data) { 
    if (error) { 
     if (!error) { 
     context.fail("Unhandled error"); 
     } 
     context.fail(error); 
    } 
    else { 
     console.log("SUCCEED"); 
     context.succeed(data); 
    } 
    }); 

}; 

そして、これはjwtManagerです:事前に

"use strict"; 
require("dotenv").config({ silent: true }); 

let jwksClient = require("jwks-rsa"); 
let jwt = require("jsonwebtoken"); 

module.exports.validate = function(params, callback) { 
    var token = validateParams(params); 

    var client = jwksClient({ 
    cache: true, 
    rateLimit: true, 
    jwksRequestsPerMinute: 10, 
    jwksUri: process.env.JWKS_URI 
    }); 

    var decodedJwt = jwt.decode(token, { complete: true }); 
    var kid = decodedJwt.header.kid; 

    client.getSigningKey(kid, function(error, data) { 
    if (error) { 
     console.log(error); 
     callback(error); 
    } else { 
     var signingKey = data.publicKey || data.rsaPublicKey; 
     jwt.verify(
     token, 
     signingKey, 
     { audience: process.env.AUDIENCE, issuer: process.env.ISSUER }, 
     function(error, decoded) { 
      if (error) { 
       console.log("ERROR"); 
       console.log(error); 
       callback(error); 
      } 
      else { 
       console.log(decoded); 
       var response = { 
        principalId: decoded.sub, 
        policyDocument: getPolicyDocument("Allow", params.methodArn), 
        context: { 
         scope: decoded.scope 
        } 
       } 
       console.log(response); 
       console.log(response.policyDocument); 
       callback(null, response); 
      } 
     } 
    ); 
    } 
    }); 
}; 

function validateParams(params) { 
    var token; 

    if (!params.type || params.type !== "TOKEN") { 
    throw new Error("Expected 'event.type' parameter to have value TOKEN"); 
    } 

    var tokenString = params.authorizationToken; 
    if (!tokenString) { 
    throw new Error("Expected 'event.authorizationToken' parameter to be set"); 
    } 

    var match = tokenString.match(/^Bearer (.*)$/); 
    if (!match || match.length < 2) { 
    throw new Error(
     "Invalid Authorization token - '" + 
     tokenString + 
     "' does not match 'Bearer .*'" 
    ); 
    } 

    return match[1]; 
} 

function getPolicyDocument(effect, resource) { 

    var policyDocument = {}; 
    policyDocument.Version = '2012-10-17'; // default version 
    policyDocument.Statement = []; 
    var statementOne = {}; 
    statementOne.Action = [ 'execute-api:Invoke', 'lambda:Invoke'] ; // default action 
    statementOne.Effect = effect; 
    statementOne.Resource = resource.split('/')[0] + '/*'; 
    policyDocument.Statement[0] = statementOne; 
    return policyDocument; 
} 

感謝を!

+0

ポリシーステートメントを印刷し、正しいIdがあることを確認しましたか? – Kannaiyan

+0

APIゲートウェイがラムダからの応答を受信しないようにリクエストしたときにラムダがトリガしないので、私のエラーと何か関係があるかどうかはわかりません –

答えて

1

カスタム承認者が接続されているが、認証ラムダ機能が実行されていないAPIゲートウェイをテストすると、トークンヘッダー名/トークンパターンの検証に失敗した可能性があります。

問題を再現できます。

オーソライザは、POSTMANのヘッダ名を "Authorization"から "AuthorizationToken"に変更した場合にのみトリガされます。

check the token header name I made the authorizer works

は、私は、彼らがいない長い前にAPI Gatewayの承認者を設定するためのUIを変更しました気づいたとして、それはおそらくAWSポータルの新しいバグだと思います。

HTTPリクエストで、名前が "AuthorizationToken"のヘッダーにベアラトークンを送信する必要があるのは非常に奇妙です。 AWS計画で技術サポートへのアクセスが許可されている場合は、この問題について警告する必要があります。

+0

ちょっと男、method.request.header .AuthorizationTokenをトークンソースとして使用した場合、またはそれをmethod.request.header.Authorizationとして残し、ヘッダーをイメージに表示したときに送信しましたか?途中で助けてくれてありがとう。 –

+0

10月にカスタムオーソライザをテストしたときに受け取ったHTTPエラーコード401は、カスタムでトークンソースとして「認可」を指定したときにauthラムダ関数に入る前に検証に失敗したAWSの一時的なバグが原因です承認者の設定。今再テストしたところ、問題は修正されました。今すぐチュートリアルに戻ってみてください。 –

0

この問題をどのように解決したか説明したいと思います。

まず、カスタムオーソライザはauthorizationTokenフィールドに常にベアラトークンを必要としますが、これは業界標準であるため、Postmanや他のクライアントからAPIゲートウェイを呼び出して、認証ヘッダーに「ベアラトークン」を送信することができますそれを支持した。

ここでのトリックは、 'カスタム認証者'を設定する際に 'トークンソース'にあります。私はここにイメージを添付しました。ここでは、「トークンソース」を設定できます。このフィールドは、カスタムオーソライザへの入力が「認証ヘッダー」からのものであることを示します。 enter image description here この方法では、引き続きpostmanの「Authorzation」ヘッダーにトークンを送信できます.API GatewayはカスタムAuthorizerのラムダを呼び出しながら、Authorizationヘッダーからコピーし、それを 'authorizationToken'入力フィールドにコピーします。

enter image description here 希望です。詳細が必要な場合はお知らせください。

関連する問題