传统 Web 应用程序和 API 中的身份验证、授权和会话管理 [英] Authentication, Authorization and Session Management in Traditional Web Apps and APIs

问题描述

如果我错了，请纠正我:在传统的Web应用程序中，浏览器会自动将会话信息附加到服务器的请求中，因此服务器可以知道请求来自谁.实际上到底附加了什么?

Correct me if I am wrong: In a traditional web application, the browser automatically appends session information into a request to the server, so the server can know who the request comes from. What exactly is appended actually?

但是，在基于 API 的应用程序中，此信息不会自动发送，因此在开发 API 时，我必须检查自己是否请求来自经过身份验证的用户?这通常是如何完成的?

However, in a API based app, this information is not sent automatically, so when developing an API, I must check myself if the request comes from an authenticated user for example? How is this normally done?

推荐答案

HTTP 协议在设计上是无状态的，每个请求都是单独完成的，并在单独的上下文中执行.

HTTP Protocol is stateless by design, each request is done separately and is executed in a separate context.

会话管理背后的想法是将来自同一客户端的请求放在同一上下文中.这是通过服务器发出标识符并将其发送给客户端来完成的，然后客户端将保存此标识符并在后续请求中重新发送，以便服务器可以识别它.

The idea behind session management is to put requests from the same client in the same context. This is done by issuing an identifier by the server and sending it to the client, then the client would save this identifier and resend it in subsequent requests so the server can identify it.

在典型的浏览器服务器情况下；浏览器为每个域管理一个键/值对列表，称为 cookie:

In a typical browser-server case; the browser manages a list of key/value pairs, known as cookies, for each domain:

• 服务器可以使用 Set-Cookie HTTP 响应头管理 Cookie(创建/修改/删除).
• 服务器可以通过解析 Cookie HTTP 请求头来访问(读取)Cookie.

• Cookies can be managed by the server (created/modified/deleted) using the Set-Cookie HTTP response header.
• Cookies can be accessed by the server (read) by parsing the Cookie HTTP request header.

面向Web的编程语言/框架提供了更高层次处理cookies的功能，例如PHP提供了setcookie/$_COOKIE 写入/读取 cookie.

Web-targeted programming languages/frameworks provide functions to deal with cookies on a higher level, for example, PHP provides setcookie/$_COOKIE to write/read cookies.

回到会话，在典型的浏览器服务器情况下(再次)，服务器端会话管理利用客户端 cookie 管理.PHP 的会话管理 设置会话 ID cookie 并使用它来识别后续请求.

Back to sessions, In a typical browser-server case (again), server-side session management takes advantage of client-side cookie management. PHP's session management sets a session id cookie and use it to identify subsequent requests.

现在回到你的问题；由于您将负责设计 API 并对其进行记录，因此实现将是您的决定.你基本上必须

Now back to your question; since you'd be the one responsible for designing the API and documenting it, the implementation would be your decision. You basically have to

1. 通过响应正文(XML/JSON 身份验证响应)内的 Set-Cookie HTTP 响应标头，为客户端提供一个标识符.
2. 具有维护标识符/客户端关联的机制.例如，将标识符 00112233445566778899aabbccddeeff 与客户端/用户 #1337 关联的数据库表.
3. 让客户端在所有后续请求中重新发送在 (1.) 处发送给它的标识符，无论是在 HTTP Cookie 请求标头中，还是在 ?sid=00112233445566778899aabbccddeeff参数(*).
4. 使用 (2.) 中的机制查找接收到的标识符，检查身份验证是否有效，并被授权执行请求的操作，然后代表已授权用户继续执行操作.

1. give the client an identifier, be it via a Set-Cookie HTTP response header, inside the response body (XML/JSON auth response).
2. have a mechanism to maintain identifier/client association. for example a database table that associates identifier 00112233445566778899aabbccddeeff with client/user #1337.
3. have the client resend the identifier sent to it at (1.) in all subsequent requests, be it in an HTTP Cookie request header, a ?sid=00112233445566778899aabbccddeeff param(*).
4. lookup the received identifier, using the mechanism at (2.), check if a valid authentication, and is authorized to do requested operation, and then proceed with the operation on behalf on the auth'd user.

当然你可以建立在现有的基础设施上，你可以在你的应用程序中使用 PHP 的会话管理(这会处理 1./2. 和 4. 的身份验证部分)，并要求客户端实现做 cookie管理(这将处理 3.)，然后您在此基础上执行其余的应用逻辑.

Of course you can build upon existing infrastructure, you can use PHP's session management (that would take care of 1./2. and the authentication part of 4.) in your app, and require that client-side implementation do cookie management(that would take care of 3.), and then you do the rest of your app logic upon that.

(*) 每种方法都有缺点和优点，例如，使用 GET 请求参数更容易实现，但可能有安全隐患，因为 GET 请求会被记录下来.您应该将 https 用于关键(所有?)应用程序.

(*) Each approach has cons and pros, for example, using a GET request param is easier to implement, but may have security implications, since GET requests are logged. You should use https for critical (all?) applications.

这篇关于传统 Web 应用程序和 API 中的身份验证、授权和会话管理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！