I have tested the following login flow (pseudo-code) with Azure AD / Oauth2 / Graph. It works perfectly:
Redirect in browser to MS365 for token: https://login.microsoftonline.com/$tenantid/oauth2/v2.0/authorize?client_id=$appid (more GETters set, omitted for brevity) This means that tenant ID and app ID is fully visible to everyone.
If already logged in, the MS token is returned to my application via redirect. If not logged in, a MS365 auth procedure is initialized, and the redirect-with-token is executed when successful.
My server does a back-channel connect to https://graph.microsoft.com/v1.0/me/ with the header "Authorization: Bearer $ms365token". The returned value is checked for userPrincipalName and this user is assumed to be logged in (I am fully aware that this opens up for token-stealing, this is not important right now in this test phase).
My questions are as follows:
a) Is the app ID really a security risk? In many places it is mentioned that it shouldn't be shown in clear text. However this seems to be hard to avoid, without encrypting the entire string, or doing some previous back-channel "login token" request (I don't know if there is such a method). Some MS sources seem to acknowledge that it is indeed pointless to hide the app ID.
b) I haven't used a client secret at all. How is this to be implemented in this scenario? Would it really increase security?
The flow is fully working, I am just unsure of the validity of the flow, and the point in trying to hide the app ID if I have to send a client secret in its place.
Let me answer the questions
a) App ID Security: Exposure of Client ID, It's generally considered acceptable for the client to know the client_id does not need to be kept secret. It's used by the authorization server (Azure AD) to identify the application that is making the request.
The security risk of exposing the client_id is minimum, especially if you are using the authorization code flow and properly validating tokens on the server side. The client ID alone is not sufficient for someone to impersonate your application.
b)The client secret is used in confidential client scenarios where the client (your server) can securely store and use the secret. It's used to authenticate your application to the authorization server during token exchange.
If your application is a public client, meaning it runs on a device that cannot be trusted to securely store the secret, using the client secret might not be appropriate. Instead, public clients often use other means of authentication, such as PKCE.
PKCE is an additional layer of security for public clients that can't securely store a client secret. It involves creating a secret for each authorization request and verifying it during the token exchange.