# How apps can access CDF
This unit explains how once you have the identity of a client or app in the customer's AAD (in the form of an app registration), the app or client will, depending on the type of client, be at different levels of risk when trying to get the token. The way the app or client gets a token needs to be adapted to the risk level.
# Client credentials for long-running, standalone applications
Let’s take the simplest example first. You have a Python script running locally on your computer, it’s secure, and it has a start and a stop time. However, you expect it to run for several hours, so you don’t want to sit there and wait. You also don’t want it to run as you, since it will only operate on some of the data in CDF, and you want to ensure that the script runs with the least number of privileges to avoid that something bad happens if you have made a mistake in the script.
In this case, we want to create a local app registration in the AAD instance. This is quite similar to the janitor case if it were possible to restrict the janitor’s access to where the light switch was in the room (obviously not, this is where the analogy breaks down).
The OAuth2 standard, which is used to make the secure exchanges to get a token, specifies an interaction flow called client credentials for this case. Here, the AAD app registration gives you a client id and a client secret. You configure your script with these values, and the Python script interacts with the CDF project and the AAD instance using an OAuth2 client credentials flow to get a time-limited token. As long as you secure your script, intercepting the communications will only yield a token that is not valid for long. The Python app also gets a refresh token that it can use to get a new token. This can continue for days and months.
# Implicit for interactive web applications
So, what about the CDF portal application? How does that work? First of all, we have a global client id as the app registration is global (or federated). We cannot store secrets for all customers, but can we store a single global secret in the CDF portal application?
Browser applications are hard (impossible) to make truly secure, so that is not an option. Instead, we use another OAuth2 communication flow that is called implicit.
In this flow, you have to interact as part of the sign-in process to approve that the CDF portal application can get a token on your behalf. This token is time-limited, but the CDF portal application will NOT get another token that it can use to refresh the session! When the token expires, the CDF portal application has to recheck with the organization's AAD to see if you are signed in to AAD in your browser. If not, it will prompt you to sign in again. If you are signed in, and the session has not timed out (dependent on the organization's security policies), the CDF portal application will silently get another token in the background.
How does this compare to our hotel analogy? Basically, this would be the same as if you were present in the room while the janitor fixed the lights, but the janitor had to use their own key card to get in and could only stay there alone for a few minutes. If you left, and you were not present the next time the janitor needed to verify with you that they were allowed to stay, the hotel security system would throw them out of your room!
# Authorization code grant for mobile and desktop applications
A third key situation where an application or client needs a token is where the standalone application (like a mobile app) runs for an extended period. In this case, it is possible to store a client id and a client secret securely inside the application. The use case is still interactive, but the application can continue in the background for an extended period without you (or AAD) confirming that the access is still allowed.
In this case, we combine the two previous cases, where both the client credentials AND your interactive approval are required. This allows the app to both get a token and a refresh token, and to continue to get renewed access without your approval. We refer to this OAuth2 communication flow as an authorization code grant with PKCE.