If a person enters in their OpenId authentication provider as: http://www.myopenid.com ... how can I discover that the real endpoint I need to 302 redirect them to is https://www.myopenid.com/server ?
BTW: I only know https://www.myopenid.com/server is the endpoint because I've been manually snopping the traffic in my browser (eg. when I attempt to login in on StackOverflow via their MyOpenId icon/pic).
Any clues, please?
OpenID 2.0 Specification explains the discovery process [1]. There are three discovery methods discussed in the specification.
XRI Resulution
Yadis Protocol
HTML Based Discovery
The libraries you are using to implement the OpenID Relying Party should be supporting these methods, so they would calculate the OP endpoint.
[1]. http://openid.net/specs/openid-authentication-2_0.html#discovery
Related
We have a Mulesoft Cloudhub environment which we are planning to deploy public APIs and we also have a VPC configured where we will deploy private APIs.
I'm looking at how best to secure the APIs and seen the following approaches:
Basic Authentication
Client Id and secret
OAuth
LDAP
SAML
My query is when should you use each one? Are their example use cases? E.g. OAuth seems to be more secure than basic authentication and client id and secret so why not use OAuth all the time and forget about the other two?
Thanks
OAuth is geared more towards authorisation rather than just authentication.
For example OAuth 2 has many different flows geared towards different use-cases. Such as 3 legged OAuth allowing you to use an external identity provider allow users to be authorised to access your resources. In a way, you’re not performing any authentication at all.
Http basic can still have a purpose in simple scenarios MAYBE when the cost and/or effort of using something else is not worth it and it’s internal network and the OJ already have some sort of ldap or active directory type thing is use for other apps (and using SSL is very important here as basic auth credentials are plain text)
For client id and secret, although it is similar to username/password, it’s more in the semantics - you are trusting a client rather than a person with the credentials.
For example, you can use client id to authenticate actual clients like a mobile application or a web app. Client id implementation like MuleSoft’s API Manager also allow you to add policies such as rate limiting and SLA based rate limiting so you can limit specific client applications to not overload your API.
You could use it alongside OAuth. Client ID/Secret for accessing the API but OAuth for authorising the end-user .
Here is a more detailed article discussing the pros and cons of the various common api auth mechanisms and a link to choosing between the various OAuth flows for your use-case.
https://nordicapis.com/3-common-methods-api-authentication-explained/
https://auth0.com/docs/api-auth/which-oauth-flow-to-use
In a microservice architecture, an API gateway lays in front of the API. The purpose of this is e.g. changing some request / response parameters, for single entry point or checking authentication etc. Now I would like to protect my API using OAuth2 flows to obtain an access token. The problem is to decide who is the actual OAuth client, I will demonstrate it by using a SPA example:
a) Is it the SPA that started the oauthorize request (to the api gateway) by using the implicit grant. Then, the Api gateway would simply route the request through to the OAuth authorization server, acting as a single entry point, with the /authorize stuff from the implicit flow
b) Is it the API Gateway itself, meaning the SPA sends the username and password of the enduser to the api gateway (of course, here the SPA needs to be trusted with the end users credentials), which then acts on its own as an oauth client using the resource owner password grant
c) dismiss the api gateway at all and create the oauth authorization server "parallel" to the api gateway, meaning you would loose the single entry point etc.
The following picture demonstrate a very abstract architecture, and the question is about the numer "[2]", if this request is initiated by the SPA and passed through by the api gateway, or if the api gateway is intercepting the request and acting on its own as an oauth client?
OAuth with API Gateway
My guess is to always use the best fitting grant type for a specific client, regardless of an API gateway being in between or not. This would mean, that when it comes to OAuth, the API Gateway would simply pass the client authorization request through, whatever grant type it used. Therefore, [2] in the picture would come from the client, and not from the API Gateway acting as the OAuth client. Is this correct? As mentioned, this really gets tricky when it comes to first party apps as you probably could use the password credentials grant, which has huge drawbacks,e.g. no refreshing possible for SPAs.
Please bear in mind that this is a purely opinion based answer, because your question is pretty vague.
I don't like the idea about using the API Gateway as the point which authenticates requests. I think that this defeats the Single Responsibility Principle. The gateways purpose usually is to expose your backend to external clients, perhaps change the contract for some specific clients, etc. But it shouldn't also authenticate calls. Besides it would have to do so based on the data passed to it, which you would have to gather somewhere else anyway.
Another thing which is I think undesirable, is that you're considering using the resource owner password grant for your SPA. This is not the correct use case for this grant flow. You could look into this article, which explains it much better than I could: https://www.scottbrady91.com/OAuth/Why-the-Resource-Owner-Password-Credentials-Grant-Type-is-not-Authentication-nor-Suitable-for-Modern-Applications
I would suggest you use the Implicit grant type and use the api gateway to only route calls to the backend, don't authenticate the calls on that layer.
If you're using a spring cloud api gateway (essentially a zuul proxy), you will have to add proper configuration so that it forwards all security headers and redirects. This example works for me:
server:
use-forward-headers: true
zuul:
addHostHeader: true
routes:
<your oauth server route>:
url: <your oauth server url>
path: <if youve got any prefix>
sensitiveHeaders:
stripPrefix: false
It doesn't matter, what Krzysztof Chris Mejka in previous answer like or dislike. Take a look at BCP - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#section-6
Latest recommendation from oauth working group at IETF is to use a kind of Api gateway/reverse proxy, another words - you need to keep tokens out of js entirely.
Reading over the Google OAuth docs at https://developers.google.com/identity/protocols/OAuth2WebServer#handlingresponse, I was surprised (or at least curious why) there's no documentation on state. It seems pretty important to prevent CSRF attacks (https://www.rfc-editor.org/rfc/rfc6819#section-4.4.1.8) even in the non-implicit flow.
Am I missing something that suggests state param is not absolutely necessary? Seems like it should be emphasized in the docs so people don't leave their apps with CSRF vulnerabilities.
It is mentioned but only for the HTTP/Rest examples. Take a look at the redirect section with HTTP/Rest selected.
Redirecting to Google's OAuth 2.0 server
When your application needs to access a user's data, redirect the user
to Google's OAuth 2.0 server.
HTTP/REST
Generate a URL to request access from Google's
OAuth 2.0 endpoint at https://accounts.google.com/o/oauth2/v2/auth.
This endpoint is accessible over HTTPS; plain HTTP connections are
refused.
The set of query string parameters supported by the Google
Authorization Server for web server applications are:
... Omitted text ...
state - Any string - Provides any state that might be useful to your
application upon receipt of the response. The Google Authorization
Server roundtrips this parameter, so your application receives the
same value it sent. To mitigate against cross-site request forgery
(CSRF), it is strongly recommended to include an anti-forgery token in
the state, and confirm it in the response. See OpenID Connect for an
example of how to do this.
I'm developing a web API that will be called by other web apps in the same Azure host and also other 3rd party services/ app. I'm currently looking into API Apps and API management, but there are several things unclear for me regarding security implementation:
Does API App need to have authentication when implemented with API management? If yes, what are the options? This link http://www.kefalidis.me/2015/06/taking-advantage-of-api-management-for-api-apps/ mentions "Keep in mind that it’s not necessary to have authentication on the API App, as you can enable authentication on API Management and let it handle all the details." So that means having the API App authentication to public anonymous? But then someone who knows the direct URL of the API App can access it directly.
What is the best way to implement API Management security? The one mentioned in the tutorial (Having a raw subscription key passed in the header) seems to be prone to man in the middle attack
What advantages does API App add instead of implementing with normal Web API project?
Thanks in advance.
I can answer from API Management perspective. To secure the connection between API Mgmt and your backend (sometimes called last-mile security), there are a few options:
Basic Authentication: this is the simplest solution
Mutual certificate authentication: https://azure.microsoft.com/en-us/documentation/articles/api-management-howto-mutual-certificates/ - this is the most common approach.
IP Whitelisting: if you have a Standard or Premium tier APIM instance, the IP address of the proxy will remain constant. Thus you can configure firewall rules to block unknown IP addresses.
JWT token: if your backend has the capability to validate JWT tokens, you can block any callers without a valid JWT.
This video might also be helpful: https://channel9.msdn.com/Blogs/AzureApiMgmt/Last-mile-Security
I think the document meant you can do the JWT token validation in APIM. However, to prevent someone calling your backend directly, you'll have to implement one of the options mentioned above in your Api Apps
From most of the reading I've done on OpenID, it seems a browser may be required. I'm writing a WCF app and wanted to use OpenID as the authentication method, but my app is not a web app. Is it possible to use WCF and OpenID together without requiring a web browser?
While OpenID can tout in its spec independence from cookies and such because the spec doesn't actually mandate how those things are used, in reality I've never seen a good OpenID solution for anything besides logging into a web site, which is really its primary use case.
However there is a good way to go and still use WCF and OpenID. Add OAuth to the mix. The DotNetOpenAuth library has a sample that shows how a WCF client can get authorized to call a WCF service via OAuth, where at the service-side the user uses OpenID to log in as part of the authorization process.
So basically if you WCF app needs to "log in" in order to call the WCF service, as part of a one-time setup:
The app pops up a browser where the user sees the WCF service web site (the OAuth Service Provider)
The user logs in with their OpenID (although the user may already be logged in, in which case they can skip this step)
The OAuth SP asks the user "do you want to authorize this [wcf app] to access this site?"
The user says yes, and closes the browser.
The WCF app now has access, thanks to the OAuth protocol, to the WCF service.
This works because behind the scenes, when the user says "yes" to the service through the web browser, a special machine-friendly credential is assigned to the WCF app, which it uses with every WCF service call the a similar way a username/password would be.
Check out the DotNetOpenAuth library. It has the sample and everything you should need to get this working.
From reading the OpenID Authentication 2.0 Specification, I seem to have arrived at an answer:
While nothing in the protocol requires JavaScript or modern browsers, the authentication scheme plays nicely with "AJAX"-style setups. This means an end user can prove their Identity to a Relying Party without having to leave their current Web page.
OpenID Authentication uses only standard HTTP(S) requests and responses, so it does not require any special capabilities of the User-Agent or other client software. OpenID is not tied to the use of cookies or any other specific mechanism of Relying Party or OpenID Provider session management. Extensions to User-Agents can simplify the end user interaction, though are not required to utilize the protocol.
Now I just need to figure out a clever way to get it to work with a WCF-based relying party...
Take a OpenIdMembershipProvider (maybe others exist).
Then configure Message security in WCF, with Username authentication, then you can use the ASPNET MembershipProvider to authenticate your user.
I don't think you can find an easier solution ;)