My app uses REST calls to fetch data from the server. To make the server calls secure, I googled and found out that OAuth is the best way to secure REST web services. But also it says that OAuth should be used with HTTPS.
If we are using HTTPS (which is a secure was to transmit data), why do we require to implement OAuth? Shouldn't HTTPS suffice?
A typical REST API needs the following capabilities:
Server Authentication - so the client requestor can verify the server. This is why browsers show a lock and display certificate information in the browser window.
Client Authentication - so the server can authenticate and identify the user to grant and limit access as appropriate.
Encryption - to protect the data from eavesdroppers.
While some simple APIs may not require client authentication, it provides two benefits that many REST APIs need:
Personalized and private data: if the user has an account on the system and needs privileges to their account, but not others, client authentication is necessary
Rate limits: even if there is no private data, services may want to differentially limit and/or charge for requests and a mechanism is needed to identify the user to limit and/or charge for access.
A typical REST API can support both Server Authentication and Encryption with HTTPS / TLS using a server TLS certificate.
HTTPS can support client authentication using a TLS client certificate, however, this is not commonly done. Some APIs such as the Visa API do this which is described here:
https://developer.visa.com/vdpguide#twoway_ssl_mutual_authentication
OAuth is much more common for client-authentication. OAuth further supports both 2-legged and 3-legged modes, the latter of which allows a separate service to perform the authentication. This is what enables login services such as those provided by Google and Facebook, so a site, such as Stack Overflow can delegate authentication to Google and then once the user's identity is verified, allow the user access permitted resources.
While Grokify's answer clarify some information, I like to mention a missing fact.
OAuth is based on tokens (ex:- Access token, refresh token). Think these tokens as username/password equivalent. So if these token get stolen, they can be used to call your API to obtain data. Or can be used for malicious activity till they expires. As you have figured out, TLS (HTTPS) protect data in transit. So when tokens transmit over such secure channel, you avoid tokens getting stolen. This is why TLS is a must for OAuth. OAuth get leverage of TLS to improve its security aspects.
Related
I am trying to make a desktop application with Twitch API and Google API.
Since this application requires Twitch user permission, a user needs to authorize my application through twitch's OAuth and I think there's no way to omit this process.
Now, I want to add some functionalities from Goole APIs, for instance TTS.
My application will be installed and run on user's local machine,
it cannot store API key or credential information safely.
I think I have three options:
Add Google OAuth: This is most safe way, I think, but I don't think I can convince users to authorize another Google account even though they already authorized their Twitch account.
Make a kind of proxy server which verifies request for Google API using twitch authentication information and relays request to/response from Google API. This seems feasible but it requires additional payment to running server for sending data from Google API. I already have to pay for TTS service, another payment for proxy server which sends binary data frequently would be a financial burden for me.
Make a server to acquire API key for Google API. This also requires additional server, but it does not involve lots of traffic because application will access Google API directly once API key acquired. However, I concern that the API key may be easily stolen using monitoring tool such as wireshark.
Which method should I use here, and how can I improve it?
Or, is there better way for this case?
We have an in-house OAuth2 server used by our applications. Now we want to use Windows SSO for our applications but without them to change anything: they'll still reach our OAuth2 server for an access token and the authentication part will be delegated to Kerberos (which Windows use, if I understood properly).
Is there a way to do that?
That is a standard setup and should just require configuration changes in the Authorization Server (AS) - with zero code changes in applications.
Most commonly:
The AS might be hosted in the cloud
It will redirect browsers to an on premise Identity Provider (IDP)
The IDP can connect to Active Directory
You may also need a fallback option for when users are not joined to the work domain. See this Curity guide for an example and some infrastructure factors to think about.
If the AS is in house it may even be able to make a direct Kerberos connection via an LDAP data source, though the preferred architecture is a separate IDP.
Of course you need an AS that supports the ability to make this type of connection, so would need to check the vendor docs.
REQUEST FLOW
Kerberos has always been the simplest protocol conceptually but the deepest to understand - here is a bit of a summary:
Your apps will make a standard OpenID Connect authorization redirect to the AS
The AS may then present an authentication selection screen to the user, unless there is only a single option
Alternatively an app can send the acr_values query parameter to say which authentication method to use
The AS will then redirect the browser to the next stage of processing, that uses a 'Windows SSO authenticator'
The redirect to the Windows SSO authenticator does not have to use OpenID Connect - it could be any vendor specific HTTP request
The browser will send an encrypted Kerberos ticket automatically by connecting to AD - a prerequisite for this to work might be that the domain in the URL is in the Local Intranet zone on end user computers
The Windows SSO authenticator will need to be able to decrypt this credential, which typically requires a Service Principal Name to be configured
Once the Kerberos ticket is decrypted, the authenticator will make an LDAP connection to an Active Directory data source via its standard LDAP endpoints, to verify the received ticket
I am trying to create jmeter script for login in to iphone native app. App is using cognito to authenticate the user.
As response of first page of app I am getting SALT and Secret block.
I am passing this secret block in and other required parameters in next request, however I got error message as "User name or password is in correct".
Did anyone worked successfully on similar things which can help me.
Looking into Amazon Cognito page:
Social and enterprise identity federation
With Amazon Cognito, your users can sign in through social identity providers such as Google, Facebook, and Amazon, and through enterprise identity providers such as Microsoft Active Directory via SAML.
Standards-based authentication
Amazon Cognito User Pools is a standards-based Identity Provider and supports identity and access management standards, such as Oauth 2.0, SAML 2.0, and OpenID Connect.
You will not be able to record and replay none of the mentioned protocols, depending on underlying identity provider mechanism you will either need to apply advanced correlation or a way to provide the required Bearer Token.
So you need to identify which identity mechanism is used under the hood and amend your JMeter test accordingly.
Reference material:
How to Load Test SAML SSO Secured Websites with JMeter
OpenID Connect - How to Load Test with JMeter
How to Run Performance Tests on OAuth Secured Apps with JMeter
I have several Web PI endpoints currently secured with an access key. I'm not opposed to abandoning this security model.
Now, we're building a web app that will consume the services. The front end will have a login screen to secure portions of the application. I also want to make the Web API services available for use by applications other than our own (think public API).
How should I secure my services and allow access from our own web UI and as a service?
There are many ways to secure Web API 2.0 endpoints.
It seems like you already secured your endpoint with an access key, no idea how your clients know the access key.
For your web app I would ask:
How is the user logging in as you described? What authority are they providing their credentials to? Can you use that authority to attach a token to the requests of your web service?
You mention you also want to provide a public access through a public api. What credentials will they have? What authority will they request access from? You could set this up many ways with different types of credentials e.g. user name and password/client certificate/access key.
Microsoft has some really good resources about this including:
http://channel9.msdn.com/Shows/Web+Camps+TV/Securing-ASPNET-Web-APIs
http://www.asp.net/web-api/overview/security
I can think of:
HTTP Basic Authentication
OAuth/OpenID Connect
Client and Server Certificates
We have a Windows app hosting a WebBrowser control that hits our REST APIs. We like to restrict access to the APIs to be only coming from withing the Windows app itself (for example, the APIs cannot be accessed in a browser, etc).
How can we accomplish that? what is the most secure way without having to expose any kind of credential (for example, if we use HTTP Basic auth, the username and password can be seen by reverse engineering the app itself)?
Thanks a bunch!
EDIT: We plan to distribute the application freely so we have no control over where the connection will be made from.
Restrict the REST interface to only accept connections from 127.0.0.1 (home) and then connect from your rest-consuming application only with http://localhost or http://127.0.0.1 in the URLs (if you use the external IP or DNS name of your machine it'll be treated as a remote connection and denied access).
You can do this with web server settings, or within the code of your REST APIs
I had a similar situation during a project where we distributed an iPhone app that also connected to a REST api that my team developed.
For security we used somewhat of a three-legged scenario. The app was required to authenticate using the user's credentials against a standalone service responsible only for authenticating and generating access tokens. Once the app received a valid access token, subsequent requests to the api required sending this token in the Authorization header.
You could do something similar. If you come up with a credential scheme to authenticate your app as valid API consumers you could use basic auth over HTTPS to obtain tokens, and then only by using those tokens could a consumer gain access to the rest of the API.