본문 바로가기
WIKI 기술 지식 베이스

Auth 서비스

원문 보기 위키 갱신

이 서비스는 토큰과 그 관련 자격 증명 객체 표현의 생성과 검증을 다뤄요.

출처: 문서

본문

이 서비스는 토큰과 그 관련 자격 증명 객체 표현의 생성과 검증을 다뤄요. 들어오는 토큰을 검증하고, 다른 서비스를 호출하기 위한 토큰을 생성하는 데 사용할 수 있어요.

HTTP 요청/응답 흐름에서 자격 증명을 구체적으로 다루고 싶다면 httpAuth 서비스도 참고하세요. 인증된 사용자에 대한 소유권 엔터티 참조 같은 더 자세한 정보를 추출하려면 userInfo 서비스를 사용하세요.

서비스 사용

다음 코드 예시에서 auth와 httpAuth 변수는 각각 의존성 주입된 coreServices.auth와 coreServices.httpAuth 서비스 인스턴스라고 가정해요. 백엔드 플러그인의 경우 다음과 같을 수 있어요:

export default createBackendPlugin({  pluginId: 'my-plugin',  register(env) {    env.registerInit({      deps: {        auth: coreServices.auth,        httpAuth: coreServices.httpAuth,        httpRouter: coreServices.httpRouter,      },      async init({ auth, httpAuth, httpRouter }) {        // Your code goes here      },    });  },});

요청 토큰 생성

다른 백엔드 플러그인에 요청을 하는 데 사용할 수 있는 토큰을 만들어야 한다면:

const { token } = await auth.getPluginRequestToken({  onBehalfOf: await auth.getOwnServiceCredentials(),  targetPluginId: 'catalog',});

참고

토큰을 저장하고 재사용하지 마세요. 항상 요청을 하기 직전에 getPluginRequestToken을 호출하세요. 그렇지 않으면 만료된 토큰이 요청에 사용될 때 권한 문제가 발생할 위험이 있어요.

이 예시는 "자신의 플러그인으로서" 요청해야 할 때, 즉 코드가 호출의 원래 개시자일 때 적합해요. 예를 들어 다른 서비스의 콘텐츠를 색인하는 주기적 배치 프로세스가 있을 수 있어요.

다른 사람을 대신해(on-behalf-of) 호출하는 상황, 예를 들어 요청 핸들러 내에서 업스트림 요청을 할 때는 요청에서 추출된 자격 증명을 항상 대신 사용하세요.

router.get('/makes-calls', async (req, res) => {  const { token } = await auth.getPluginRequestToken({    onBehalfOf: await httpAuth.credentials(req),    targetPluginId: 'catalog',  });});// make a call using the token

이렇게 하면 원래 호출자와 그 관련 권한이 요청 체인을 따라 제대로 전달돼요. 자세한 내용은 httpAuth 서비스 문서를 참고하세요.

서비스 간 인증 문서 에는 HTTP 요청 경로에서 토큰을 올바르게 사용하는 방법에 대한 더 자세한 내용이 있어요.

토큰 승인

대부분의 플러그인은 들어오는 요청 토큰을 직접 다뤄서는 안 되고, 요청 핸들러의 일부로 httpAuth.credentials를 대신 사용해야 해요. 하지만 들어오는 토큰을 보유하고 그것을 검증해 자격 증명 객체로 바꾸고 싶은 드문 경우에는 이렇게 할 수 있어요:

const credentials = await auth.authenticate(token);

쿠키 기반 접근을 다루는 플러그인을 특별히 만들었다면(드문 경우) { allowLimitedAccess: true }로 설정할 수 있는 선택적 두 번째 매개변수가 있어요.

자격 증명 검사

auth 서비스에는 자격 증명 객체를 다루기 위한 기능도 있어요. 예를 들어 어떤 유형의 주체(호출자 유형, 예: 사용자 또는 서비스)를 나타내는지 확인할 수 있어요. 예를 들어:

if (auth.isPrincipal(credentials, 'user')) {  // In here, the TypeScript type of the credentials object has been properly  // narrowed to `BackstageCredentials<BackstageUserPrincipal>` so you can  // access its specific properties such as `credentials.principal.userEntityRef`.}

서비스 구성

참고

auth 서비스는 사설 저장소에서 구현을 완전히 교체하는 데 적합하지 않아요. 추가 서비스 인증 관련 기능이 필요하다면 주저하지 말고 이슈를 등록하거나 오픈 소스 기능에 기여하세요.

서비스 간 접근 방법 구성은 auth 문서 를 참고하세요.

기본 auth 정책은 모든 요청이 사용자 또는 서비스 자격 증명으로 인증되도록 요구해요. 이는 backend.auth.dangerouslyDisableDefaultAuthPolicy app-config 플래그를 true로 설정해 비활성화할 수 있어요. 이 검사를 비활성화하면 백엔드가 더 이상 인증되지 않은 요청을 차단하지 않고 플러그인으로 통과시키도록 허용할 뿐이에요. 꼭 필요한 경우가 아니면 프로덕션에서 이렇게 하지 마세요.

권한이 활성화되면 인증되지 않은 요청은 그 자체로 정확히 그렇게 취급되며, 권한 정책이 인증되지 않은 ID에 어떤 권한이 허용되어야 하는지 결정하도록 맡겨요. 서비스 호출용 자격 증명을 구성하지 않는 한 이는 플러그인 간 서비스 간 호출에도 적용된다는 점에 유의하세요.

더 알아보기 (Learn more)