feat: Update README

Author: coreone

docs/README.md

@@ -36,16 +36,63 @@ Other endpoints we hope to add in the near future:
 
 You can use pip to install cert_manager:
 
-```Shell
+```shell
 pip install cert_manager
 ```
 
+## Authentication
+
+Originally, Certificate Manager only allowed username and password, or client
+certificate and key as methods of authenticating to the REST API. However,
+OAuth2 is now supported via a completely different URL structure. This new model
+can be used by swapping out the `Client` class with `OAuth2Client`. You need to
+provide a Client ID and Client Secret to `OAuth2Client`, which you create via
+the UI in [Sectigo][2]. Information on how to create the Client ID and Client
+Secret can be found on
+[How Do You Implement OAuth 2.0 for SCM](https://www.sectigo.com/knowledge-base/detail/implement-oauth-2-0-for-scm)
+page.
+
+The following is an example of creating the `OAuth2Client` object:
+
+```python
+from cert_manager import OAuth2Client
+client = OAuth2Client(
+    client_id="client-id-from-sectigo", client_secret="client-secret-from-sectigo",
+)
+```
+
+This client should then be usable by all of the existing classes in the library
+in place of the original. However, pay particular attention to the version of
+the API you are using for each class. Typically the version is `v1`, but there
+isn't a consistent version across all endpoints. You may need to add
+`api_version` to many of the object instantiations for the API to work
+correctly. A complete API reference can be found on the
+[SCM DevX](https://scm.devx.sectigo.com/reference/) site. This, for example, is
+the first code snippet in [Examples](#examples) rewritten for the new API
+infrastructure:
+
+```python
+from cert_manager import Organization
+from cert_manager import OAuth2Client
+from cert_manager import SSL
+
+client = OAuth2Client(
+    client_id="client-id-from-sectigo", client_secret="client-secret-from-sectigo",
+)
+
+org = Organization(client=client)
+ssl = SSL(client=client, api_version="v2")
+
+print(ssl.types)
+print(org.all())
+```
+
 ## Examples
 
 This is a simple example that just shows initializing the `Client` object and
 using it to query the `Organization` and `SSL` endpoints:
 
-```Python
+```python
 from cert_manager import Organization
 from cert_manager import Client
 from cert_manager import SSL
@@ -67,7 +114,7 @@ print(org.all())
 The most common process you would do, however, is enroll and then collect a
 certificate you want to order from the Certificate Manager:
 
-```Python
+```python
 from time import sleep
 
 from cert_manager import Organization
@@ -128,7 +175,7 @@ To start a development environment, you should be able to just run the
 to build a [Docker][4] container with all the dependencies for development
 installed using [Poetry][3].
 
-```Shell
+```shell
 ./dev.bash
 ```
 
@@ -147,7 +194,7 @@ access token. We currently use
 for this purpose. The following should generate the file using information from
 GitHub:
 
-```Shell
+```shell
 docker run -it --rm \
     -e CHANGELOG_GITHUB_TOKEN='yourtokenhere' \
     -v "$(pwd)":/working \
@@ -158,7 +205,7 @@ docker run -it --rm \
 To generate the log for an upcoming release that has not yet been tagged, you
 can run a command to include the upcoming release version. For example, `2.0.0`:
 
-```Shell
+```shell
 docker run -it --rm \
     -e CHANGELOG_GITHUB_TOKEN='yourtokenhere' \
     -v "$(pwd)":/working \
@@ -179,14 +226,14 @@ version bumps as part of a PR, so you don't want to have [bump2version][6] tag
 the version at the same time it does the commit as commit hashes may change.
 Therefore, to bump the version a patch level, one would run the command:
 
-```Shell
+```shell
 bump2version --verbose --no-tag patch
 ```
 
 Once the PR is merged, you can then checkout the new `main` branch and tag it
 using the new version number that is now in `.bumpversion.cfg`:
 
-```Shell
+```shell
 git checkout main
 git pull --rebase
 git tag 1.0.0 -m 'Bump version: 0.1.0 → 1.0.0'