Auth0 규칙은 Auth0이 제공하는 확장 및 사용자 정의 인증 파이프라인의 메커니즘입니다.그들은 사용자가 비밀번호를 제공하거나 이메일 주소나 전화번호로 보내는 코드/링크를 입력해서 신분을 증명한 후에 실행한다.JWT의 로드를 수정하고 사용자가 MFA 도전을 완료하거나 중간 페이지로 방향을 바꿀 수 있는 매우 강력한 도구입니다.규칙 코드를 사용하는 기본 방식은 AUth0 콘솔을 통해서입니다.나는 컨트롤러에서 코드를 편집하는 것을 그다지 좋아하지 않는다.테스트가 너무 어렵고 코드의 변경을 추적할 명확한 방법이 없습니다.실행 중인 내용이 원본 코드 관리의 내용과 일치하지 않거나 원본 코드 관리에 아무런 내용이 없습니다.
이 문서에서는 Auth0 배포 CLI와 Github 작업을 사용하여 Auth0 규칙의 연속 통합과 연속 교부를 설정하는 방법을 소개합니다.이 문장 (이 문장 포함) 의 모든 내용의 코드는 this Github repository 에서 찾을 수 있다.

설치 프로그램 인증 0

첫 번째로 해야 할 일은 Auth0을 설정하여 코드로 전송하는 것을 받아들이는 것이다.
Auth0에는 CI/CD의 Auth0 섹션을 가장 간단하게 작업할 수 있는 확장 기능이 있습니다.
설치하기

extensions(확장) 창으로 이동

deploy cli 확장 클릭

설치에 동의하고 필요한 범위에 접근할 수 있습니다.

이것은 auth0-deploy-cli-extension 이라는 새 Auth0 프로그램을 만들 것입니다. 이 프로그램은 임대인에 기본 설정된 Auth0 Management API 을 사용하여 전체 임대인을 수정할 권리가 있습니다.

규칙 코드

각 규칙에는 Auth0 웹 작업 환경(NodeJS 12)에서 실행되는 함수만 포함됩니다.남다른 것은 그것이 반드시 단일한 함수여야 한다는 것이다.콘솔에서 예제 규칙을 만들 때는 다음과 같습니다.

function (user, context, callback) {
  // Ok there is more code here in the sample but you get the idea.
}

컨트롤러에서 작성하는 것 외에는 단원 테스트를 작성하기 어렵다.내가 하고 싶은 것은 단원 테스트를 작성하는 것이다. 이런 테스트는 코드 경로를 연습하고 내가 생산 환경에 더욱 쉽게 납품할 수 있도록 할 수 있다.
Jest와 같은 테스트 프레임워크에서 작업하기 위해서는 함수를 내보내야 합니다.웹 작업 환경은 그 작업 원리를 매우 구체적으로 설명한다.이것은 es모듈에 적용되지 않으며 전역 module 속성도 공개하지 않습니다.Auth0 환경에서 module.exports = rule 또는 export rule 를 실행하려고 하면 오류가 발생하여 사용자가 로그인할 수 없습니다.
해결 방법은 코드를 즉시 실행되는 익명 함수에 포장하고 module 존재하지 않으면 규칙 함수를 되돌려주고 존재하면 이 함수를 내보내는 것이다.Jest 테스트 실행기 모듈에서 실행될 때 이런 방식이 존재하고 코드가 내보내지지만 Auth0 환경에서는 규칙만 되돌아오면 코드가 실행될 수 있습니다.
보아하니 약간 이렇다.

(() => {
  function rule(user, context, callback) {
    // TODO: implement your rule
  }
  if (module) {
    module.exports = rule;
  } else {
    return rule;
  }
})() // prettier-ignore

이 블록에서 주의해야 할 것은 마지막 줄에 구분이 없다는 것이다.여기서 세미콜론을 사용하면 Auth0 규칙에 오류가 발생할 수 있습니다.이것이 바로 // prettier-ignore가 존재하는 이유입니다. 제가 저장할 때마다Prettier는 번호를 추가합니다.
그것만 있으면 코드를 Jest 테스트에 가져올 수 있습니다. 그러면 인증 흐름의 일부분으로 실행되는 코드가 실제로 작동할 수 있다고 확신할 수 있습니다.

Auth0 Deploy CLI 사용

Auth0 deploy CLI는 Auth0 관리 API와의 상호 작용을 나타내는 도구입니다.Auth0 Deploy CLI는 로컬, 글로벌 또는 npx 설치를 사용하여 실행할 수 있는 NPM 패키지입니다.만약 피할 수 있다면, 나는 차라리 전 세계에서 어떤 것도 운행하는 것을 피하고 싶다.프로젝트에 Deploy CLI를 설치하고 npm 스크립트에서 실행했습니다.

구성 설정

구성 파일은 json 파일로 함께 배치할 수 있습니다.필요한 최소값은 AUTH0_DOMAIN, AUTH0_CLIENT_SECRET 및 AUTH0_CLIENT_ID 입니다.AUTH0_ALLOW_DELETE 속성을 추가하고true로 설정하면 Auth0에 저장된 코드에 존재하지 않는 규칙을 삭제합니다.
내 파일에서, 나는 이 ##variable## 기호를 사용했는데, 이것은 내가 파라미터의 값을 환경 변수로 전달할 수 있도록 한다.이것은 Github 작업과 쉽게 통합되고 의외의 기밀 제출을 피할 수 있도록 도와줍니다.맵 교체에 대한 추가 정보in the Auth0 documentation를 찾을 수 있습니다.

{
  "AUTH0_DOMAIN": "##AUTH0_DOMAIN##",
  "AUTH0_CLIENT_SECRET": "##AUTH0_CLIENT_SECRET##",
  "AUTH0_CLIENT_ID": "##AUTH0_CLIENT_ID##",
  "AUTH0_ALLOW_DELETE": true
}

Auth0에 배포

규칙을 설정하는 데 필요한 것은 코드만이 아니다.다음 YAML 파일은 사용자가 성공적으로 로그인한 후 첫 번째 규칙으로 실행되고 환경 변수로 전달될 기밀로 구성됩니다.이 YAML 파일은 필요에 따라 가능한 한 많거나 적은 임차인 설정을 포함할 수 있습니다.이런 상황에서 나는 이 배치를 규칙만 갱신하는 것으로 유지한다. 왜냐하면 그들은 자신의 변경 주기가 있기 때문에 세입자의 나머지 부분과 다르기 때문이다.

rules:
  - name: sampleRule
    script: ./rules/sampleRule.js
    stage: login_success
    enabled: true
    order: 1
rulesConfigs:
  - key: "ItsASecret"
    value: "##SECRET_IN_ENV_VARIABLES##"

규칙을 세입자에게 가져오기

테스트 배포

위에서 설정한 설정은 rules/sampleRule.js 기호를 사용하여 환경 변수를 설정에 주입하기 때문에 이 명령을 실행하려면 Auth0 컨트롤러가 필요합니다.Auth0 확장으로 생성된 ## 응용 프로그램의 구성 값을 가져옵니다.auth0-deploy-cli,AUTH0_DOMAIN,AUTH0_CLIENT_SECRET,AUTH0_CLIENT_ID이라는 as 환경 변수를 설정합니다.

환경 변수에 설정을 추가하고 import 문장을 실행합니다. 예를 들어 a0deploy import -c ./config.json -i ./src/tenant.yaml.
Auth0 컨트롤러의 코드를 확인하여 이 코드가 배치된 코드와 동일한지 테스트합니다.
완성된 후, 나는 코드를 규칙에 배치할 수 있으며, 그것을 컨트롤러에 복사할 필요가 없다.이것은 앞으로 내딛는 큰 걸음이다.다음에 해야 할 일은 코드가 버전 제어에 들어갈 때 자동으로 이 점을 실현하는 것이다.

Github에서 작업 실행

자동화된 연속 통합과 연속 배치를 위해 Github 작업을 사용했습니다.나는 이 활동을 두 부분으로 나누었다.푸시할 때마다 실행되는 테스트가 있고, 실제로 코드를 Auth0에 배치합니다.두 번째는 코드가 main 지점에 제출될 때만 실행됩니다. 기능 지점에서 개발을 할 수 있고 코드가 완성될 때만 활동 환경에 배치할 수 있습니다.
첫 번째 작업은 Auth0 배포와 관련이 없기 때문에 코드를 이해할 수 없습니다.흥미가 있으면 찾을 수 있다here.
두 번째 일은 더욱 관련이 있다.우선 Ubuntu에서 실행되도록 설정하지만 build 작업이 완료되고 main 지점에서만 실행됩니다.

deploy:
  runs-on: ubuntu-latest
  if: github.ref == 'refs/heads/main'
  needs:
    - build

코드를 검사하고 NodeJS 12를 설정하고 프로젝트 의존 항목을 설치하는 절차를 밟을 것입니다.이 경우 이러한 종속성에는 Auth0 Deploy CLI가 포함됩니다.

steps:
  - uses: actions/checkout@v2
  - uses: actions/setup-node@v2-beta
    with:
      node-version: "12"
  - name: NPM Install
    run: npm install

다음 단계는 Auth0에 실제로 배포됩니다.이 단계에서, 이 변수는 Github 컨트롤러에 업로드된 기밀에서 나오는 환경 변수를 설정합니다.설정이 완료되면 실행npm run deploy됩니다. 이것은 실행a0deploy import -c ./config.json -i ./src/tenant.yaml의 NPM 스크립트입니다.

- name: Push to Auth0
  env:
    AUTH0_DOMAIN: ${{secrets.AUTH0_DOMAIN}}
    AUTH0_CLIENT_SECRET: ${{secrets.AUTH0_CLIENT_SECRET}}
    AUTH0_CLIENT_ID: ${{secrets.AUTH0_CLIENT_ID}}
  run: npm run deploy

마지막

이렇게 끝났어.하나 이상의 규칙에 대한 단위 테스트를 실행한 후에, 나는 자동으로 그것을 Auth0에 배치할 수 있다.이런 방법은 나로 하여금 배치된 코드에 대해 더욱 자신감을 가지게 하고, 어떠한 규모의 팀에서도 일할 때 매우 중요하다.

As a final note the Auth0 Deploy CLI can be used to deploy pretty much all of your Auth0 configuration. If you are using Auth0 for production workloads I'd strongly suggest using a configuration as code approach to keep track of changes to your environment and allow testing changes in staging environments.

Different sections of the config (rules, custom login pages, applications, hooks, etc) can be stored in different repositories to reflect it's rate of and reasons to change.

표지 사진 작가 hannah grace