I have the following doubt, I have a project that is based on microsoft authentication, a frontend with angular using msal and the backend with passport-azure-ad.
My question is the following, is it necessary to use the client secret?
When we are using authorization code flow or hybrid flow in OpenID Connect, the client exchanges an authorization code for an access token. During this step, the client has to authenticate itself to the server. One way to authenticate the client is by using a client secret.
Client secret is required for web apps which can store the client_secret securely on the server side.All confidential clients have a choice of using client secrets or certificate credentials and passport azure ad library is designed for auth flows in server side web apps.
Note:ClientID and Client Secrets are passed to AAD by MSAL, and if you are using a confidential client (like: WebApp, WebAPI or
Daemon/Service) that runs on Azure PaaS Service, or any other secured
servers, only the clientID gets exposed by MSAL but not the client
secret, as the client secret is passed only in the backend (server
side) to AAD and never directly exposed and requires proper
authentication.
msal client apps
If your app is native(spa), client secret is not needed
Public clients, which include native applications and single page apps, must not use secrets or certificates when redeeming an authorization code as client_secret can't be reliably stored on devices or web pages and the secret can be vulnerable to attacks if it is client side exposed..
Reference: v2-oauth2-auth-code-flow-Client secret
Related
I am planning to deploy a separate resource server and an authorisation server, both running on django oauth toolkit. Assuming that the clients or the applications using our API services are in the same organization, and will host their frontend to use our APIs, and the users will be logged in on their side and we just have to authorize those clients (that are running the application).
Which Grant Type Should I use?
RFC 7636: Proof Key for Code Exchange
PKCE (RFC 7636) is an extension to the Authorization Code flow to prevent CSRF and authorization code injection attacks.
PKCE is not a replacement for a client secret, and PKCE is recommended even if a client is using a client secret.
Note: Because PKCE is not a replacement for client authentication, it does not allow treating a public client as a confidential client.
PKCE was originally designed to protect the authorization code flow in mobile apps, but its ability to prevent authorization code injection makes it useful for every type of OAuth client, even web apps that use a client secret.
I have a web app MyWebApp.
And two APIs: MyAuthAPI and MyServiceAPI, both RESTful NodeJS. MyAuthAPI uses HashiCorp Vault as a token store with OAuth2.
MyServiceAPI has CRUD operations available to authenticated clients.
There is no human login required (or desired) on MyWebApp. Any human can access MyWebApp through a browser and run the service.
At present, this is the (very insecure) flow:
MyWebApp sends clientid and clientsecret to MyAuthAPI to retrieve token. This token is then used for communicating with MyServiceAPI.
The obvious downside is that anyone can capture the clientid and clientsecret by simply looking in developer tools in a web browser. They could then use those to authenticate with MyAuthAPI, generate their own token, and make calls to MyServiceAPI without MyWebApp being involved.
So how do I best secure the entire application so that MyWebApp is safely and robustly authenticated without revealing the credentials?
Thanks.
ETA:
I want to be able to authenticate MyWebApp with MyAuthAPI and then use the generated token to connect to MyServiceAPI. But I don't want it to be possible that anyone can intercept those credentials - currently they can be see in the request header as "Authorization: Basic "
The MyServiceAPI endpoints must be secured so that only authenticated clients are able to access them. But when that client (MyWebApp) is a public website, how do I authenticate without making the credentials visible?
ETA2:
https://mywebapp.com is MyWebApp which is a React application.
https://myauthapi.com hosts MyAuthAPI
https://myserviceapi.com hosts MyServiceAPI
When I load mywebapp.com in a web browser, it authenticates with myauthapi.com/oauth/token to get a token. At present it does this by sending the creds in the header Authorization: Basic
The token that is returned is then saved.
The web application then tries to get the data from an endpoint on MyServiceApi using this token:
Authorization: Bearer
GET https://myserviceapi.com/objects
or POST myserviceapi.com/objects
or GET myserviceapi.com/objects/objectid
or DELETE myserviceapi.com/objects/objectid
MyServiceAPI verifies the token with MyAuthAPI, but that isn't public-facing, so there's no issue there.
The issue is that, as you can see from the attached screenshot of the Developer Tools console in Chrome, anyone using the web application can see the Authorization header containing the credentials, and could then use these credentials to programatically gain access to the auth API to generate a token which can then be used on the service API endpoints.
I want to restrict all access to the API servers to only come from specific applications, such as MyWebApp, on mywebapp.com.
First, I think this question could better be asked in https://softwareengineering.stackexchange.com/.
Second, where MyWebApp is deployed? How it is being used? If it works with https, then the body is encrypted, and when you send the clientId and clientSecret, you should send it in the body, so users will not be able to see them.
Client Credentials Grant should only be used by confidential Clients. Thats because you can't hide the client_secret on non confidential Clients. Your frontend seems to be a non confidential Client.
Normally you should use the Authorization Code Grant with PKCE. But you would need users to authenticate themselves for that.
Feels like you need an architecture design based on standard flows, since OAuth should work like this:
Web app signs user in via an Authorization Server, using Authorization Code Flow (PKCE)
Web app gets tokens from the Authorization Server
Web app calls API with an access token
API validates token using data from the Authorization Server
API then trusts claims in the access token and uses them for authorization
See my Initial HTTP Messages blog post for an example of how this looks.
I started working with instagram APIs using node.js and walked through the official instagram API docs here but it does not explain clearly.
Here I have 2 questions:
what is the difference between Client ID and Client Secret?
what is access_token ? and what is it used for ? and
when we should request for it ?
The client ID is is basically a unique id assigned to your application by an Oauth provider. It considered public information, and is used to build login URLs, or included in Javascript source code on a page.
An app requesting an access token has to know the client secret in order to gain the token. This prevents malicious apps from ever obtaining a valid access token. The client secret id doesn't state anything about authenticating a user, but it's instead for authorising an app to request access tokens.
The client secret must be kept confidential. If a deployed app cannot keep the secret confidential, such as single-page Javascript apps or native apps, then the secret is not used.
When you login with an Oauth provider, the server responds with an access token and expiration time in ms if the login is successful.
{
"access_token":"RsT5OjbzRn430zqMLgV3Ia",
"expires_in":3600
}
Every time client requests a resource from the server, the server validates the access code. The access-token is used to verify every request from the client. You will request for an access_token whenever you login through an Oauth provider.
You can refer this and this for more information.
When an Android oauth 2.0 client application has client ID and client Secret hard-coded in it. it is very easy to decompile the application and retrieve the credentials.
Then What is the use of providing these credentials to oauth server.
It is not recommended to hard-code client_id and client_secret into a native app i.e. to use what is called a "confidential client" in a mobile app scenario exactly because the client_secret cannot be kept a secret.
A native app would typically be a "public client" to the Authorization Server i.e. one that does not have a client_secret. Security would come from the fact that a unique redirect URI is registered and additional OAuth features like PKCE (https://www.rfc-editor.org/rfc/rfc7636) are applied.
For general recommendations on using OAuth 2.0 for native apps see: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps, especially the security considerations at: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps-10#section-8
I'm building an Angular 2 application using SAML2 via the passport-wsfed-saml2 strategy https://github.com/auth0/passport-wsfed-saml2. When I receive a users info back from SAML I generate a JWT token which I use to authenticate a user on an API I am also writing.
So I have two servers, APP/Auth Server is serving my application as well as generating my JWT tokens and API Server has my API. Both servers have a copy of the JWT secret, so when a user sends a request from APP/Auth Server to the API Server I verify the token they sent with their request by verifying it with the secret.
Now for my questions, is it bad practice to have your app served from the same server you use to generate your JWT tokens? If so, what should I do here? Should I be doing more to authenticate a user on my API side?
Something about this just feels dirty....any help would be appreciated.
Having the application and authentication system in the same service is not a malpractice by itself. In general, decoupled services are recommended but this does not mean that the deployment can group services and of course depends on the context
If you are worried about sharing the secret key among servers, you can use an asymmetric key pair (private and public). The private key only needs to be known by the Auth Server in order to sign the JWT. The API Server can use the public key to verify tokens.