Page History

...

The Wikipedia article on HTTP Basic Authentication provides an easy to understand overview of how usernames and passwords are to be BASE64 Base64 encoded and then added to the HTTP Authorization request header. API testing tools like Postman make this very easy to implement. Here's a simple guide:

...

1. Click the Authorization tab (Note: Even though the term Authorization is used, it is technically Authentication).
2. Pick HTTP Auth as the authentication type from the dropdown.
3. Enter the Username and Password (for demonstration purposes, the above screenshot uses the same username and password that was auto-generated by the Web Accounts form). You might want to enable the Show Password chekbox as well.
4. Click on the Preview Request button. This last step is necessary to transfer the authentication information into the HTTP Authorization request header. You can confirm this by clicking on the Headers tab (the one to the right of the Authorization tab):
   

The HTTP request can now be submitted by clicking the Send button and the SRP HTTP Framework should identify the username and password correctly and return an appropriate response. We'll discuss how APIs can identify the username and password used in the HTTP request for authorization purposes in another article.

Using Non-Authenticated URLs

Non-Authenticated URLs are special URLs that are intended to by-pass the default authentication requirements. That is, even if you have HTTP Authentication enabled, any URL that appears in the list of non-authenticated URLs will be accepted automatically. Note, these URLs (or endpoints) do not need to include the Home and API URL portion.

The purpose of this list is to allow requests between trusted servers to be processed automatically. A common example of this is with OAuth. OAuth works when the server you are trying to access makes a request of a 3rd party (e.g., Facebook, Google, Microsoft, etc.) for an access token. This access token grants the requesting server access to various resources on the 3rd party platform (also known as the identity provider). This negotiation between the requesting server and the identity provider is handled behind the scenes through trusted URLs. Since an identity provider cannot be expected to know how to authenticate itself to any and every requesting server, it is expected that the requesting server provides at least one URL that can be reached without any authentication.