기본 HTTP 및 Bearer 토큰 인증

기본 HTTP 및 Bearer 토큰 인증

---

현재 개발 환경을 위해 HTTP-Basic으로 보호되는 REST-API를 개발 중입니다. 실제 인증은 토큰을 통해 이루어지기 때문에 두 개의 인증 헤더를 보내는 방법을 알아 내려고 여전히 노력하고 있습니다.

나는 이것을 시도했다 :

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Authorization: Bearer mytoken123"

예를 들어 내 IP에 대한 HTTP 인증을 비활성화 할 수 있지만 일반적으로 동적 IP를 사용하는 다른 환경에서 작업하기 때문에 이것은 좋은 솔루션이 아닙니다. 그래서 내가 뭔가를 놓치고 있습니까?

---

URL에서 기본 인증을 푸시하려면 다음을 시도하십시오.

curl -i http://username:password@dev.myapp.com/api/users -H "Authorization: Bearer mytoken123"
               ^^^^^^^^^^^^^^^^^^

위의 방법이 작동하지 않으면 그와 관련이 없습니다. 따라서 다음 대안을 시도하십시오.

다른 이름으로 토큰을 전달할 수 있습니다. 귀하는 귀하의 애플리케이션에서 승인을 처리하고 있기 때문입니다. 따라서 이러한 특수 목적을 위해 이러한 유연성을 쉽게 사용할 수 있습니다.

curl -i http://dev.myapp.com/api/users \
  -H "Authorization: Basic Ym9zY236Ym9zY28=" \
  -H "Application-Authorization: mytoken123"

헤더를 Application-Authorization. 따라서 응용 프로그램에서 해당 헤더 아래에있는 토큰을 잡고 필요한 작업을 처리합니다.

또 다른 방법 token은 POST매개 변수 를 전달 하고 서버 측에서 매개 변수 값을 가져 오는 것입니다. 예를 들어 curl post 매개 변수를 사용하여 토큰을 전달합니다.

-d "auth-token=mytoken123"

---

표준 ( https://tools.ietf.org/html/rfc6750 )은 다음을 사용할 수 있다고 말합니다.

• 양식 인코딩 본문 매개 변수 : 승인 : Bearer mytoken123
• URI 쿼리 매개 변수 : access_token = mytoken123

따라서 URI로 많은 Bearer Token을 전달할 수 있지만 이렇게하는 것은 권장되지 않습니다 (표준의 섹션 5 참조).

---

사이에 nginx와 같은 역방향 프록시를 사용하는 경우 X-API-Token.

nginx에서는 업스트림 프록시 (나머지 API)가 인증이되도록 다시 작성합니다.

proxy_set_header Authorization $http_x_api_token;

... nginx는 원래 Authorization 헤더를 사용하여 HTTP AUth를 확인할 수 있습니다.

---

비슷한 문제가 발생했습니다. 장치에서 장치와 사용자를 인증했습니다. Cookie헤더와 함께 헤더를 사용했습니다 Authorization: Bearer....

---

컬 --anyauth

curl에게 자체 인증 방법을 파악하고 원격 사이트에서 지원한다고 주장하는 가장 안전한 방법을 사용하도록 지시합니다. 이는 먼저 요청을 수행하고 응답 헤더를 확인하여 수행되므로 추가 네트워크 왕복이 발생할 수 있습니다. --basic, --digest, --ntlm 및 --negotiate를 사용하여 수행 할 수있는 특정 인증 방법을 설정하는 대신 사용됩니다.

참고 URL : https://stackoverflow.com/questions/22229996/basic-http-and-bearer-token-authentication