I have an application for Windows in C# and i wanted to connect to Google calendar. In the tutorials and documentation example here they require some client secret which is to be generated when requesting client ID for a service account. But it's not. However I can see the public key fingerprints and I installed a certificate that was generated when I requested the client ID.
My guess is that their documentation is outdated. Can anyone give me a tutorial/reference or explain how this is should work now?
Thanks
Last time I used Google Calendar API you did not need a Client Secret for Oauth Service Account authorization. You just need Application ID, private key and the service account email address if I am right. I used it with java, but here is an example for .NET if it can help you.
https://developers.google.com/api-client-library/dotnet/guide/aaa_oauth#service_account
According to RFC 6749 (OAuth 2.0), the token endpoint of OAuth 2.0 authorization server requires client authentication in the following cases.
The client type of the client application is confidential.
The client type of the client application is public but the client application has been issued client credentials (client_id + client_secret).
To put it the other way around, client authentication is not required (so client_secret is not needed) when the client type of the client application is public and the client application has not been issued client credentials.
By definition, a public client cannot keep its client credentials confidential. Therefore, in general, implementations of OAuth 2.0 authorization servers won't issue a client secret for public client applications. It sounds that Google's implementation behaves so, too.
Probably, the reason Google did not issue a client secret to your application was that the client configuration you choiced had made your client application a public client.
The public key fingerprint is a different matter. RFC 6749 (OAuth 2.0) does not mention anything about public keys. Instead, I guess it may be related to OpenID Connect Core 1.0, OpenID Connect Dynamic Client Registration 1.0 (especially token_endpoint_auth_method), or Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants. You have to read Google's document to know what the public key fingerprint is for.
Related
I new to keycloak and oauth2 and I need your help.
I'm planning to develop a public API so my customers client applications/serivces could perform some actions in the system without human interaction. Therfore I need to let them a way to authenticate to the API with a "service-account" and an "API key".
I found that the "oauth2 way" to do it called "2-legged" and it's actually the client credential grant type.
I'm trying to understand how to configure keycloak to achive that. I found the following stack-overflow answer, but the author of the answer wrote in a comment "I haven't worked with Keycloak in a while though, so this approach might be out of date."
As I understand the answer, I need to create a client for each external client with the following configuration:
Access Type: confidential
Standard Flow Enabled: OFF
Direct Access Grants Enabled: OFF
Service Accounts Enabled: ON
And I need to configure some Scope. Which I don't completely understand.
The external client will get the credentials(client id and a secret) belongs to his specific client.
And in order to perform requests against the public API he will ask keycloak for a valid token and then send the requests with that token to my public API.
My questions are:
Is this is the right way to do it using keycloak?
Is it possible to configure keycloak in a way that each external client will be configured as a user and not as a client in keycloak but still support in client credential grant type?
How my public API can validate the token? I must send a request to keycloak to validate the token? or I can validate it with some certificate?
Please advice,
Thanks!
I write a rest api with yii2 and i am using oAuth2 , the problem is when user want login , client web application should send request to get token , request should contain client_id and secret_key and username and password in this case user can simply inspect element and click to network and see posted parameter to the server this means user can see client_id and secret_key.
client_id and secret_key are signature for each application and server can find out witch application use api.
how to handle this security issue?
It seems you have missed out one key element of OAuth 2.0, client type.
OAuth 2.0 defines two types of clients, public clients and confidentiatl clients.
2.1. Client Types
confidential
These are the clients which can protect a credential. They have the
full potential to use authorization code grant type, which obtain
token from backchannel request. Because they use backchannel to obtain
tokens, their credentials are never exposed to end user(via user
agent)
public
Clients which cannot protect credentials. For example SPA clients and
mobile apps comes to this category.
In your case, you seems to have a public client (user agent based application in broswer as it seems). In such case, you should set your client type to a public client. If this is not the case, you are not utilizing a proper back channel call from your web application.
Additionally, public clients which use authorization code flow can use PKCE to avoid authorization code theft attacks. Related RFC can be found from RFC7636
I'm currently trying to implement the OAuth 2.0 authorization code grant on a public client/native client (Android App).
Since it is impossible to store the client_secret on the device, I wanted to use this grant type with rfc7636 / Proof Key for Code Exchange by OAuth Public Clients (PKCE).
I'm using wso2 5.3.0 IAM in the backend.
The Authorization step works perfectly fine, but I'm not able to get the Access Token without a client_secret: invalid_request, Missing parameters: client_secret
Did I misunderstand the authorization code grant with PKCE wrong or did I miss some configuration in the IAM?
In comparison: It is possible with auth0.
Best Regards,
Robert
Even if you use the authorization code flow, client_secret is required at the token endpoint if the client type of your application is confidential. "4.1.3. Access Token Request" in RFC 6749 says as follows:
If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.
So, change the client type of your application to public. I don't know WSO2, but I guess that it provides settings menu to switch the client type like below.
(screenshot of Authlete's web console)
The definitions of confidential clients and public clients are described in "2.1. Client Types" in RFC 6749.
Yes, the client_secret is mandatory in WSO2 IS implementation due to the Apache OLTU library that has been used internally to implement the OAuth2 feature.
Currently there is no way to register an application as a public client as explained.
However that doesn't mean there are necessarily any security pitfalls. Basically what the recommendation says is, not to embed the client_secret in a mobile app, because it makes it vulnerable. It doesn't provide any additional security for protected backend resources, because the client request is anyway not authenticated using client_secret. If you just treat the "Base64(client_id:client_secret)" as one single string it doesn't make any difference in the protocol or security of the protocol.
So when using WSO2 IS with mobile applications, following recommendations need to be followed.
Use authorization code grant type, which requires the client_secret.
Use PKCE (after WSO2 IS 5.2.0)
If you have other type of clients or channels for the same applications, e.g. like web, then register them as a separate service provider in IS and generate a separate pair of client_id, client_secret for them.
Disable "client_credentials" grant type for the particular OAuth2 mobile client you register in WSO2 IS, so that those apps can't get an access token without user authentication.
Going one step further, if you need to have unique client credentials for each instance of the mobile applications then use OAuth2 Dynamic Client Registration (DCR) to generate client credentials on the fly.
By following above 5 recommendations, it gives you the same level of security as recommended in the specification.
For Authorization grant flow you can send the request with empty client_secret. Try putting empty string like this client_secret='' and it should work as expected. You cannot request TOKEN_URI without client_secret parameter.
PKCE is used to protect theft of authorization code, Authorization code is valid for 10 minutes, when auth code is redeemed for access_token we also send code_verifier to make sure the auth code is not stoled by someone. code_verifier and code_challenge are generated together and code_challenge is used while requesting for auth code & code_verifier is used while requesting for access_token
When requesting access to an application via OAuth 2.0 you need certain credentials. In the case of google the request URL which sends the user to a page to allow access contains the client ID and Secret. Does this not leave the data open for anyone to grab request access to apps on my applications behalf?
Also, is OAuth only possible through a browser or can it be achieved completely server side?
I'm pretty new to this so apologies if I'm missing something obvious.
Your calls to the OAuth 2.0 authorization server which contain your client ID and client secret MUST be made over an encrypted channel (= using SSL/TLS). The standard says (chapter 2.3.1):
The authorization server MUST require the use of TLS as described in Section 1.6 when sending requests using password authentication.
4.3.2 of RFC 6749 (which describes the "Resource Owner Password Credentials Grant flow" of the oauth2 Authorization Framework) states:
If the client type is confidential or the client was issued client
credentials (or assigned other authentication requirements), the
client MUST authenticate with the authorization server as described
in Section 3.2.1.
Can't seem to find a reference as to what a "confidential client" is. From this it seems that it's allowed to have non-confidential clients participate in the "Resource Owner Password Credentials Grant flow" (4.3). I.e. clients that won't (and can't) authenticate themselves with the Authorization Server.
Is this correct?
Check out the client types section, where the definition of "confidential clients" is given as:
Clients capable of maintaining the confidentiality of their
credentials (e.g., client implemented on a secure server with
restricted access to the client credentials), or capable of secure
client authentication using other means.
Cloudfoundry's command-line cf application is an example of a "public" (i.e. non-confidential) client which uses the password grant.
Section 2.3 of the oauth2 specification has the following paragraph:
The authorization server MAY establish a client authentication method with public clients. However, the authorization server MUST NOT rely on public client authentication for the purpose of identifying the client.
Where a public client is defined in section 2.1 as:
Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.
So, you can (optionally) authenticate the client but not take that the mean that the client is who it says it is.