인증
Restorm에는 “인증 유형” 드롭다운이 없습니다. 그보다 훨씬 일반적인 것이 있습니다. 바로 인증 요청 인데, 다른 요청들이 쓸 헤더를 만들어 내는 역할을 맡은 독립적인 요청입니다.
장점은 어떤 방식이든 표현할 수 있다는 점입니다. 두 단계로 이루어진 교환, 서명된 토큰, 자체 제작 API처럼 어떤 드롭다운도 미리 준비해 두지 않는 방식까지 포함됩니다. 단점은 한 번은 직접 작성해야 한다는 점입니다.
인증 경로 만들기
Section titled “인증 경로 만들기”변수 폴더를 오른쪽 클릭한 뒤 추가 ▸ HTTP 인증 요청을 선택하십시오.
먼저 다른 HTTP 요청과 똑같이 호출을 구성합니다. 메서드, URL, 헤더, 본문입니다. 그다음 설정 탭을 열면 인증에 고유한 세 가지 항목이 있습니다.
생성되는 헤더
Section titled “생성되는 헤더”이 경로를 참조하는 모든 요청에 주입할 헤더 목록입니다. 각 값은 인증 요청의 응답 본문에 대해 평가되는 표현식입니다.
| 헤더 | 값 |
|---|---|
Authorization | {{token_type}} {{access_token}} |
역시 응답 본문에 대해 평가되는 표현식으로, 유효 기간을 초 단위로 알려 줍니다.
보통 {{expires_in}} 을 씁니다. 비워 두면 토큰이 스스로 만료되지 않습니다.
인증 오류 코드
Section titled “인증 오류 코드”이 경로를 사용하는 요청이 받았을 때 토큰 갱신 후 자동 재시도를 일으키는
HTTP 상태 코드입니다. 기본값은 401 과 403 입니다.
두 용어, 하나의 대상
Section titled “두 용어, 하나의 대상”인증 요청은 트리 안에서 만드는 요소입니다. 인증 경로는 다른 요청 쪽에서, 그 요청에 연결하는 선택기를 통해 바라본 동일한 요소입니다. 두 용어는 인터페이스의 서로 다른 위치에서 같은 엔티티를 가리킵니다.
요청에 경로 연결하기
Section titled “요청에 경로 연결하기”요청 탭의 smartbar에 있는 인증 경로 선택기가 변수 폴더의 경로들을 나열합니다. 기본 레이블은 인증 없음 입니다.
연결하고 나면 보낼 때마다 생성되는 헤더가 주입되고, 토큰은 만료될 때까지 캐시에
보관되며, 401 이 돌아오면 사용자가 눈치채지 못하는 사이에 갱신이 이루어집니다.
자주 쓰이는 구성
Section titled “자주 쓰이는 구성”Bearer / OAuth 2 client credentials
Section titled “Bearer / OAuth 2 client credentials”요청: POST https://auth.exemple.test/oauth/token, 본문은
x-www-form-urlencoded 이며 grant_type=client_credentials,
client_id={{clientId}}, client_secret={{clientSecret}} 를 담습니다
(클라이언트 시크릿은 비밀 값 유형으로 둡니다).
생성되는 헤더: Authorization = {{token_type}} {{access_token}}.
만료: {{expires_in}}.
자격 증명을 이미 가지고 있다면 요청이 필요하지 않습니다. 요청(또는 폴더)에 헤더만 지정하면 됩니다.
Authorization = Basic {{base64Encode (append (append user ":") password)}}
헤더 하나 또는 쿼리 매개변수 하나로 충분합니다. X-API-Key = {{apiKey}} 로 두고,
키는 비밀 값 유형 변수로 만듭니다.
두 번의 호출로 얻는 토큰
Section titled “두 번의 호출로 얻는 토큰”시나리오를 만드십시오. 첫 호출, 중간 코드
추출, 두 번째 호출, 그리고 변수 설정 으로 토큰을 실행 변수에 넣습니다. 시나리오의
이후 요청들은 {{jeton}} 으로 그 값을 읽습니다.
가져오기가 하는 일
Section titled “가져오기가 하는 일”명세를 가져올 때, 선언된 보안 스키마는 미리 연결된 헤더나 매개변수로 변환되고 환경 변수도 함께 만들어집니다.
| 명세의 스키마 | Restorm이 넣는 것 |
|---|---|
apiKey(헤더 또는 쿼리) | 스키마 이름을 딴 쌍, 값은 {{<schema>}} |
http / basic | Authorization: Basic {{<schema>_credentials}} |
http / bearer, oauth2, openIdConnect | Authorization: Bearer {{<schema>_token}} |
남은 일은 변수에 값을 채우는 것뿐입니다. 자동 갱신을 원하신다면 그 자리를 인증 경로로 바꾸십시오.
프로토콜별 네이티브 자격 증명
Section titled “프로토콜별 네이티브 자격 증명”일부 프로토콜은 HTTP 헤더를 거치지 않습니다. 그 자격 증명은 요청 자체의 필드입니다.
| 프로토콜 | 필드 |
|---|---|
| MQTT | username, password, 클라이언트 식별자 |
| AMQP | username, password, vhost |
| Redis | password |
| Kafka | SASL 메커니즘(plain, scram-sha-256, scram-sha-512), 식별자, 비밀번호, TLS |
| STOMP | CONNECT의 login 및 passcode 헤더 |
| gRPC | 호출 메타데이터 |
이 비밀번호들은 모두 비밀 값 유형의 값을 받아들입니다.