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.
Related
I'm struggling theese days on the possible way to configure an Authentication + authorization system to consume a REST API from a mobile application.
Scenario:
We've developed 3 independent portals for a big customer that serves several users.
To enable a SSO for the 3 portals we've implemented a SAML authentication system using SimpleSAMLphp.
Every portal has a service provider and they make assertion requests against a central IdP.
The IdP checks username and password against a database where passwords are hashed and stored during registration.
After the login, the authorization on the portals is handled by the session on the server, and so far everything was fine.
Now the customer asked us to develop a mobile application that will require the users to login and access several of their protected resources collected during the usage of the 3 portals.
We've decided to develop a frontend application using ionic that will consume a REST API made in node.js that will serve all the data (both protected and unprotected resources).
Now here comes the question: to authorize access to protected resources on the Api we'd like to use JWT to easily achieve a stateless system.
The doubt is how to perform the authentication? We've the opportunity to check the credentials directly against the database skipping the SAML process, otherwise we've to implement a solution where the SSO IdP acts as authentication provider and then when an attempt is successful the API app will get the response from the idp and then issue a signed jwt to the consumer client. Is this second way a common implementation? Is it possible?
What path do you suggest to follow? The first could be very easy to achieve, but since we're using html+js for the app's frontend, if we decide to use the second solution probably in the near future we could recycle some code from the app to modernize some functions on the web portals, maintaining the jwt pattern and consuming the new Api also on the web.
I believe that in this case will be easier to ask a token to the new api using someway the logged in user's data already in the session of the portal. Sounds possible?
I hope that everything was clear, any help will be appreciated!
Thanks
The key goal here is to code your apps in the best way, via
the latest security standards (OAuth 2.0 and Open Id Connect).
SAML is an outdated protocol that is not web / mobile / API friendly, and does not fit with modern coding models.
Sounds like you want to do OAuth but you do not have an OAuth Authorization Server, which is a key part of the solution. If you could migrate to one you would have the best future options for your apps.
OPTION 1
Use the most standard and simple option - but users have to login with a new login screen + credentials:
Mobile or Web UI uses Authorization Flow (PKCE) and redirects to an Authorization Server to sign the user in
Mobile or Web UI receives an access token after login that can be sent to the API
Access token format is most commonly a JWT that the API can validate and identify the user from
The API is not involved in the login or token issuing processes
OPTION 2
Extend option 1 to federate to your SAML Identity Provider - enables users to login in the existing way:
The Authorization Server is configured to trust your SAML based identity provider and to redirect to it during logins
The SAML idp presents a login screen and then posts a SAML token to the Authorization Server
The Authorization Server issues OAuth based tokens based on the SAML token details
OPTION 3
Use a bridging solution (not really recommended but sometimes worth considering if you have no proper authorization server - at least it gets your apps using OAuth tokens):
Mobile or Web UI uses Resource Owner Password Grant and sends credentials to a new OAuth endpoint that you develop
OAuth endpoint provides a /oauth/token endpoint to receive the request
OAuth endpoint checks the credentials against the database - or translates to a SAML request that is forwarded to the IDP
OAuth endpoint does its own issuing of JWT access tokens via a third party library (if credentials are valid)
Web or Mobile UI sends JWT access token to API
API validates received JWT access token
My current auth server doesn't support OAuth 2.0 and I'm trying to set up a new auth server. But I don't need a replacement, I just want to pass the token to my new auth server so it can give access token to a third-party application.
I've been reading many documents about OAuth2 but none of them mentioned how is the access token generated. All of them only said once the user submitted their credential to the authorizaURL, it will verify and send back a code(auth code grant) or an access token(implicit grant).
The problem is, how does the auth server generate that token and how does the resource server verify this token? And how do these two servers bounded together?
Thank you in advance : )
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
Using this example eventually I would like to send the data to my server. The question is: if someone would break client script, replace email with some other email and sand it to my server? How can it be prevented? also, according to oauth standards I should verify the data on server side using client id and secret key, but I don't see any documentation regarding that in this particular related documentation.
You would not send unprotected data from the client to the server but you would send the access token that you've used to obtain the user info to the server side so the server side can retrieve that data from Google on its own
You should be using what Google refers to as the Server Side Flow (which is really more of a hybrid flow, involving both client side and server side components).
In this setup, you use the Google+ Sign-In button to navigate the OAuth handshake, but what comes back includes a very short-lived one-time-use code. Your client then sends this to your server, which exchanges it with Google's servers for an auth token, which can be used to get the email and other user information.