|
1 | | -# oauth |
| 1 | +# Azure OAuth2 OIDC Auth Code Flow demonstration |
| 2 | + |
| 3 | +The goal of this repository is to demonstrate how to incorporate [OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749) on Azure **WITHOUT** the use of [MSAL](https://learn.microsoft.com/en-us/entra/identity-platform/msal-overview) for educational purposes. |
| 4 | +In a production environment one should **ALWAYS** use MSAL or similar battle-tested libraries, but it is vital for any engineer to understand what is going on under the hood instead of just blindly calling a library which |
| 5 | +automagically solves all your needs. |
| 6 | + |
| 7 | +The repo contains code for both the client and the server. The client is utilizing [OpenID Connect (OIDC)](https://auth0.com/docs/authenticate/protocols/openid-connect-protocol) with |
| 8 | +Auth code flow. A comprehensive step-by-step guide is included on how to register the client and server on Azure Entra ID. |
| 9 | + |
| 10 | +## Requirements |
| 11 | + |
| 12 | +- **Platform**: x86-64, Linux/WSL |
| 13 | +- **Programming Language**: [Python 3](https://www.python.org/downloads/) |
| 14 | +- **Azure Account**: Access to [Azure Subscription](https://azure.microsoft.com/en-us/pricing/purchase-options/azure-account) |
| 15 | +- **IAC Tool**: [Terraform](https://www.terraform.io/) |
| 16 | + |
| 17 | + |
| 18 | +## Allocate resources |
| 19 | + |
| 20 | +The script [up](up.sh) provisions Azure resources by applying our [Terraform script](infra/terraform.tf). |
| 21 | + |
| 22 | +It is necessary to create a file named **terraform.tfvars** in the [infra](infra) directory. This file holds sensitive information |
| 23 | +necessary for terraform to be able to interact with your cloud resources, namely that of your tenant and subscription id. |
| 24 | +An exemption for this file has been added in our [.gitignore](.gitignore) so that you do not accidentally commit it. |
| 25 | + |
| 26 | +The file structure is as follows: |
| 27 | + |
| 28 | + |
| 29 | + |
| 30 | + |
| 31 | +## Set up CI/CD via Deployment Center |
| 32 | + |
| 33 | +Now that we have our new Web App resource up and running on Azure, we may proceed to set up our means of deploying our code to the |
| 34 | +aforementioned Web App. We will do so by connecting our Web App to our GitHub repository. Azure Web Apps has the ability |
| 35 | +to create a fully fledged CI/CD pipeline in the form of a GitHub Action Workflows script, which it commits on our behalf. As part of this pipeline a managed identify |
| 36 | +will be created in Azure in order to authenticate requests. Secrets will be automatically created and referenced in the CI/CD script by Azure. |
| 37 | + |
| 38 | +Click on the **Deployment Center** section under the **Deployment** blade. Choose GitHub as source and set the appropriate organization, repository and branch. |
| 39 | +For authentication keep it as is (user-assigned identity). Click on the **Save** button in the top left corner. |
| 40 | + |
| 41 | + |
| 42 | + |
| 43 | +After the changes have persisted, navigate to your GitHub repository. A new commit which contains the CI/CD workflows file should be present. As mentioned earlier, |
| 44 | +this has been committed by Azure on our behalf. |
| 45 | + |
| 46 | + |
| 47 | + |
| 48 | +Navigate to the bottom of the workflow file. Take notice of the three secrets being referenced. |
| 49 | + |
| 50 | + |
| 51 | + |
| 52 | +If you navigate to your secrets and variables associated with your GitHub Actions you will see that there are three new secrets, the same referenced above. Again, |
| 53 | +these have been set by Azure on your behalf in order to set up authentication with our managed identity which was created as part of the Deployment Center rollout. |
| 54 | + |
| 55 | +For the CI/CD workflow script to actually work, we have to make some adjustments. Remember, this repo contains code for both the client and server - |
| 56 | +which are located in their own directories. The autogenerated script assumes that the files are located in the root folder, which is not the case here. |
| 57 | +Thus, we need to change the script to reference files located under the server directory, as we are to deploy our server. |
| 58 | + |
| 59 | +The final pipeline definition should look like [this](.github/workflows/main_hvalfangstlinuxwebapp.yml). |
| 60 | + |
| 61 | +## Deploy API |
| 62 | + |
| 63 | +In order to deploy our code to our Azure Web App slot, we need to trigger the newly registered GitHub Actions Workflow manually. Head over to the **Actions** section of your repository. Click on the **Run workflow** button located in the right corner. |
| 64 | + |
| 65 | + |
| 66 | + |
| 67 | +Running said action should result in the following: |
| 68 | + |
| 69 | + |
| 70 | + |
| 71 | +Navigate to the **Deployment Center** section of your Azure Web App. A new deployment will be visible. Commit author and message will be equal to that of GitHub. |
| 72 | + |
| 73 | + |
| 74 | + |
| 75 | +Now that we know that it deployed successfully it is finally time to access the API. Click on URI associated with **Default Domain** |
| 76 | + |
| 77 | + |
| 78 | + |
| 79 | +You will be prompted with the following default page, which indicates that the API is up and running. |
| 80 | + |
| 81 | + |
| 82 | + |
| 83 | + |
| 84 | +## Register API on Azure AD |
| 85 | + |
| 86 | +Now that we have deployed our API to Azure Web Apps, we need to register it on Microsoft Entra ID. |
| 87 | + |
| 88 | +### Create a new app registration |
| 89 | + |
| 90 | +Navigate to the **App registrations** blade and click on **New registration** button in the top left tab |
| 91 | + |
| 92 | + |
| 93 | + |
| 94 | + |
| 95 | + |
| 96 | + |
| 97 | + |
| 98 | + |
| 99 | +### Expose API |
| 100 | + |
| 101 | + |
| 102 | + |
| 103 | + |
| 104 | + |
| 105 | + |
| 106 | + |
| 107 | + |
| 108 | + |
| 109 | + |
| 110 | + |
| 111 | + |
| 112 | + |
| 113 | +## Running API |
| 114 | +```bash |
| 115 | +python -m uvicorn app.main:app --reload |
| 116 | +``` |
0 commit comments