Understanding HTTP Authentication in Postman
Most APIs require the client to prove its identity on every request, and the HTTP Authorization header is the standard mechanism for doing that. Postman's Authorization tab lets you pick an auth type — Basic Auth, Bearer Token, API Key, OAuth 2.0, and more — and it automatically builds the correct Authorization header for you instead of you typing it by hand in the Headers tab.
Cricket analogy: Just as an umpire checks a bowler's action and team sheet before every over rather than trusting a verbal claim, the Authorization header re-proves identity on every single API call, not just at the start of the match.
Basic Authentication
Basic Auth sends a username and password concatenated as username:password, Base64-encoded, and prefixed with 'Basic ' in the Authorization header. In Postman, selecting Basic Auth and filling in the Username and Password fields does this encoding automatically when the request is sent; the raw credentials are never stored pre-encoded, so you can see the generated header in the Code preview panel.
Cricket analogy: Writing a player's name and shirt number together on a single scorecard line is like concatenating username and password with a colon before Postman encodes the whole string as one token.
GET /api/orders HTTP/1.1
Host: api.example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
Accept: application/jsonBearer Token Authentication
Bearer Token auth sends a single opaque or JWT token in the header as 'Authorization: Bearer <token>', proving the client already holds a previously issued credential rather than resending a password on every call. In Postman, pasting the token into the Bearer Token field under the Auth tab, or referencing a variable like {{access_token}}, generates that header automatically for the request.
Cricket analogy: A player who has already passed the ground's accreditation check simply flashes their laminated pass at each gate for the rest of the tour, rather than re-verifying identity documents each time, much like a Bearer token replaces repeated password entry.
Postman lets a parent Collection or Folder hold the auth configuration, and child requests can select 'Inherit auth from parent' so you only update the token or credentials in one place instead of every request.
Security Considerations and Token Storage
Basic Auth credentials and Bearer tokens are only as safe as the transport and storage around them — Base64 is encoding, not encryption, so Basic Auth must always run over HTTPS, and tokens should be kept in Postman environment or collection variables (ideally marked as the 'secret' type) rather than pasted directly into the Auth tab of a shared collection.
Cricket analogy: Shouting your dressing-room door code across a crowded stand is as insecure as sending Basic Auth over plain HTTP — anyone nearby can intercept it, so you keep the code, like a token, written somewhere only you can see.
Never commit a collection export containing a hardcoded Bearer token or Basic Auth password to a public Git repository — use {{variable}} references in the Auth tab and store the actual secret values only in an environment file that is excluded from version control.
- The Authorization header is sent with every request; Postman's Auth tab builds it for you based on the auth type you select.
- Basic Auth Base64-encodes 'username:password' — this is reversible encoding, not encryption, so it must be used only over HTTPS.
- Bearer Token auth sends a pre-issued token as 'Authorization: Bearer <token>' instead of resending a password on every call.
- Postman requests can inherit auth configuration from a parent Collection or Folder to avoid duplicating credentials.
- Store credentials and tokens in Postman environment/collection variables, ideally as the 'secret' variable type.
- Never hardcode real credentials into a request's Auth tab in a shared or version-controlled collection.
- Use the Code preview panel in Postman to inspect the exact Authorization header being generated before sending a request.
Practice what you learned
1. What does Postman's Basic Auth type actually send in the Authorization header?
2. Why is Basic Auth considered unsafe over plain HTTP?
3. In Postman, what does 'Inherit auth from parent' allow you to do?
4. What is the correct Authorization header format for Bearer Token auth?
5. Where should a real API token be stored when working in a shared Postman collection?
Was this page helpful?
You May Also Like
OAuth 2.0 in Postman
Understand the OAuth 2.0 authorization framework and how to configure grant types, token retrieval, and token refresh using Postman's OAuth 2.0 Authorization tab.
API Keys and Custom Headers
Learn how to authenticate requests using API keys and how to work with custom HTTP headers in Postman, including placement options and common conventions.
Managing Secrets Safely
Learn how to store, share, and rotate API keys, tokens, and passwords in Postman using variable scopes, secret-typed variables, and Vault integration without leaking them into version control.