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에 어떤 권한이 허용되어야 하는지 결정하도록 맡겨요. 서비스 호출용 자격 증명을 구성하지 않는 한 이는 플러그인 간 서비스 간 호출에도 적용된다는 점에 유의하세요.