Return information after accepting credentials
01An authentication scheme is a named HTTP authentication method. Some schemes need a final message after the server accepts the client’s credentials.
The response carries Authentication-Info. A scheme can define server authentication or another finalization message; the generic field alone proves neither.
Source for this drawing: RFC 7615 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
A request starts a conversation.
A client asks for a resource. A server sends a response. The method, address, headers, and status explain what that conversation means.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
This guide explains the 2015 publication. Superseded by RFC 9110.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
RFC 9110 obsoletes 7615 and incorporates the fields into HTTP Semantics. This is a successor publication, not a new version of the immutable7615 text.
Read the updated RFC section ↗Authentication-Info carries scheme-specific information after credential acceptance; it is not a new challenge or an authorization decision.
- Authentication-Info carries scheme-specific information after credential acceptance; it is not a new challenge or an authorization decision.
- The Authorization scheme in the corresponding request defines the response parameters and their meaning. RFC 7615 defines no universal parameter names.
- The field can be used with any request method and response status code. Do not infer a 200-only rule or successful application operation from its presence.
RFC 7615 generalizes fields previously tied to Digest in RFC 2617. It formally obsoletes 2617, but does not independently replace all Basic/Digest rules. RFC 9110 now obsoletes 7615; its §§11.6.3 and11.7.3 carry the field semantics.
Read the RFC section ↗