기존 웹 앱 및 API의 인증, 권한 부여 및 세션 관리

기존 웹 앱 및 API의 인증, 권한 부여 및 세션 관리

---

내가 틀렸다면 정정하십시오 : 기존 웹 애플리케이션에서 브라우저는 자동으로 세션 정보를 서버에 대한 요청에 추가하므로 서버는 요청이 누구로부터 오는지 알 수 있습니다. 실제로 정확히 무엇이 추가됩니까?

하지만 API 기반 앱에서는이 정보가 자동으로 전송되지 않기 때문에 API를 개발할 때 인증 된 사용자의 요청인지 직접 확인해야합니까? 이것은 일반적으로 어떻게 이루어 집니까?

---

HTTP 프로토콜은 설계 상 상태 비 저장이며 각 요청은 개별적으로 수행되며 별도의 컨텍스트에서 실행됩니다.

세션 관리의 기본 개념은 동일한 클라이언트의 요청을 동일한 컨텍스트에 배치하는 것입니다. 이는 서버에서 식별자를 발급하고이를 클라이언트로 전송하여 수행되며, 클라이언트는이 식별자를 저장하고 서버가 식별 할 수 있도록 후속 요청에서 다시 보냅니다.

쿠키

일반적인 브라우저-서버의 경우; 브라우저는 각 도메인에 대해 쿠키라고하는 키 / 값 쌍 목록을 관리합니다.

• 쿠키는 Set-CookieHTTP 응답 헤더를 사용하여 서버에서 관리 (생성 / 수정 / 삭제) 할 수 있습니다 .
• 쿠키는 CookieHTTP 요청 헤더를 구문 분석하여 서버 (읽기)에서 액세스 할 수 있습니다 .

웹 타겟 프로그래밍 언어 / 프레임 워크는 더 높은 수준에서 쿠키를 처리하는 기능을 제공합니다. 예를 들어 PHP는 쿠키를 쓰기 / 읽기 제공 setcookie/ 제공 $_COOKIE합니다.

세션

세션으로 돌아가서, 전형적인 브라우저-서버의 경우 (다시) 서버 측 세션 관리는 클라이언트 측 쿠키 관리를 활용합니다. PHP의 세션 관리 는 세션 ID 쿠키를 설정하고이를 사용하여 후속 요청을 식별합니다.

웹 애플리케이션 API?

이제 질문으로 돌아갑니다. API를 설계하고 문서화하는 책임이 귀하이기 때문에 구현은 귀하의 결정이 될 것입니다. 당신은 기본적으로

1. Set-Cookie응답 본문 (XML / JSON 인증 응답) 내에서 HTTP 응답 헤더 를 통해 클라이언트에 식별자를 제공합니다 .
2. 식별자 / 클라이언트 연결을 유지하는 메커니즘이 있습니다. 예를 들어 식별자 00112233445566778899aabbccddeeff를 client / user #와 연결하는 데이터베이스 테이블이 있습니다 1337.
3. 클라이언트가 HTTP Cookie요청 헤더 인 ?sid=00112233445566778899aabbccddeeffparam (*)에 있는 모든 후속 요청에서 (1.)에서 보낸 식별자를 다시 보내도록합니다 .
4. (2.)의 메커니즘을 사용하여 수신 된 식별자를 조회하고 유효한 인증인지 확인하고 요청 된 작업을 수행 할 권한이 있는지 확인한 다음 인증 된 사용자를 대신하여 작업을 진행합니다.

물론 기존 인프라를 기반으로 구축 할 수 있으며, 앱에서 PHP의 세션 관리 (1./2. 및 4.의 인증 부분 처리)를 사용할 수 있으며 클라이언트 측 구현에서 쿠키 관리를 수행하도록 요구할 수 있습니다. 3.)을 처리하고 나머지 앱 로직을 수행합니다.

---

(*) 각 접근 방식에는 장단점이 있습니다. 예를 들어 GET 요청 매개 변수를 사용하면 구현하기가 더 쉽지만 GET 요청이 기록되므로 보안에 영향을 미칠 수 있습니다. 중요한 (모든?) 애플리케이션에는 https를 사용해야합니다.

---

세션 관리는 서버 책임입니다. 세션이 생성되면 세션 토큰이 생성되어 클라이언트로 전송되고 쿠키에 저장됩니다. 그 후 클라이언트와 서버 간의 다음 요청에서 클라이언트는 토큰 (일반적으로)을 HTTP 쿠키로 보냅니다. 모든 세션 데이터는 서버에 저장되며 클라이언트는 토큰 만 저장합니다. 예를 들어 PHP에서 세션을 시작하려면 다음을 수행하면됩니다.

session_start();  // Will create a cookie named PHPSESSID with the session token

세션이 생성 된 후 데이터를 저장할 수 있습니다. 예를 들어 사용자를 계속 기록하려면 다음을 수행하십시오.

// If username and password match, you can just save the user id on the session
$_SESSION['userID'] = 123;

이제 사용자가 인증되었는지 여부를 확인할 수 있습니다.

if ($_SESSION['userID'])
    echo 'user is authenticated';
else
    echo 'user isn't authenticated';       

원하는 경우 인증 된 사용자에 대해서만 세션을 만들 수 있습니다.

if (verifyAccountInformation($user,$pass)){ // Check user credentials
    // Will create a cookie named PHPSESSID with the session token
    session_start();
    $_SESSION['userID'] = 123;
}

---

웹 애플리케이션과 API 모두에 대해 진정한 사용자를위한 다양한 방법이 있습니다. 몇 가지 표준이 있거나 사용자 지정 권한 / 또는 인증을 작성할 수 있습니다. 권한 부여와 인증의 차이점을 지적하고 싶습니다. 첫째, 애플리케이션은 요청이 들어오는 사용자 (또는 API 클라이언트)를 인증해야합니다. 사용자가 인증되면 사용자의 ID 응용 프로그램에 따라 인증 된 사용자가 특정 응용 프로그램 (권한 부여)을 수행 할 수있는 권한이 있는지 확인해야합니다. 대부분의 기존 웹 애플리케이션의 경우 보안 모델에 세분화가 없으므로 사용자가 인증되면 대부분의 경우 특정 작업을 수행 할 권한도 부여됩니다. 그러나이 두 개념 (인증 및 권한 부여)은 두 개의 다른 논리적 작업이어야합니다.

또한 기존 웹 애플리케이션에서는 사용자가 인증되고 권한이 부여 된 후 (대부분 데이터베이스에서 사용자 이름 / 암호 쌍을 조회하여) 권한 부여 및 신원 정보가 세션 저장소에 기록됩니다. 세션 저장소는 위의 대부분의 답변에서 알 수 있듯이 서버 측일 필요는 없으며 대부분의 경우 암호화 된 클라이언트 측 쿠키에 저장 될 수도 있습니다. 예를 들어, PHP CodeIgniter 프레임 워크는 기본적으로이를 수행합니다. 클라이언트 측에서 세션을 보호하는 메커니즘은 여러 가지가 있으며, 세션 데이터를 저장하는이 방법은 sessionId를 저장하는 것보다 덜 안전하며 서버 측의 세션 저장소에서 조회됩니다. 또한 클라이언트 측 세션 저장은 분산 환경에서 매우 편리합니다.

더욱이, 간단한 사용자-암호 쌍으로 인증하는 모든 경우에 데이터베이스에서 일치하는 사용자 레코드를 조회하는 사용자 지정 코드를 통해 수행 할 필요는 없습니다. 예를 들어 기본 인증 프로토콜 또는 다이제스트 인증이 있습니다. Windows 플랫폼과 같은 독점 소프트웨어에는 ActiveDirectory 와 같은 사용자 통을 인증하는 방법도 있습니다.

사용자 이름 / 비밀번호 쌍을 제공하는 것은 인증 방법 일뿐만 아니라 HTTPS 프로토콜을 사용하는 경우 디지털 인증서를 사용한 인증 을 고려할 수도 있습니다 .

특정 사용 사례에서 SOAP를 프로토콜로 사용하는 웹 서비스를 설계하는 경우 SOAP 프로토콜에 대한 WS-Security 확장 도 있습니다.

이 모든 것을 말하면서 다음 질문에 대한 답변은 WebApi에 대한 권한 부여 / 인증 메커니즘 선택을위한 결정 절차를 입력합니다.

1) 대상 고객은 누구입니까, 공개적으로 사용할 수 있습니까, 아니면 등록 (유료) 회원 만 사용할 수 있습니까?
2) 실행 중인지 * NIX 또는 MS 플랫폼인지
3) 예상되는 사용자 수
4) 민감한 데이터 API가 처리하는 정도 (강력한 인증 메커니즘과 약한 인증 메커니즘)
5) 사용할 수있는 SSO 서비스가 있습니까?

.. 그리고 더 많은.

방정식에 많은 변수가 있으므로 이것이 약간의 문제를 해결하기를 바랍니다.

---

If the API based APP is a Client, then the API must have option to retrieve/read the cookies from server response stream and store it. For automatic appending of cookies while preparing request object for same server/url. If it is not available, session id cannot be retrieved.

---

You are right, well the reason things are 'automatic' in a standard environment is because cookies are preferred over URL propagation to keep things pretty for the users. That said, the browser (client software) manages storing and sending the session cookie along with every request.

In the API world, simple systems often just have authentication credentials passed along with every request (at least in my line of work). Client authors are typically (again in my experience) reluctant to implement cookie storage, and transmission with every request and generally anything more than the bare minimum...

There are plenty of other authentication mechanisms out there for HTTP-based APIs, HTTP basic / digest to name a couple, and of course the ubiquitous o-auth which is designed specifically for these things if I'm not mistaken. No cookies are maintained, credentials are part of every exchange (fairly sure on that).

The other thing to consider is what you're going to do w/ the session on the server in an API. The session on a website provides storage for the current user, and typically stores small amounts of data to take load off the db from page to page. In an API context this is less of a need as things are more-or-less stateless, speaking generally of course; it really depends what the service is doing.

---

I would suggest you send some kind of token with each request.

Dependent on the server and service those can be a JSESSIONID parameter in your GET/POST request or something mature like SAML in SOAP over HTTP in your Web Service request.

참고URL : https://stackoverflow.com/questions/10960131/authentication-authorization-and-session-management-in-traditional-web-apps-and