I'm interested in implementing an OpenID Connect RP for a web application running behind nginx, potentially using oauth2_proxy. Does oauth2_proxy support this out of the box or will additional OpenID Connect features have to be added?
oauth2_proxy has a pull request for OpenID Connect configuration discovery, but I was unable to make it work; it seemed like it wasn't getting valid json back from the https:// request. An alternative would be to code your provider's configuration in the same way that oauth2_proxy already supports Facebook and Google.
I'm not sure whether oauth2_proxy supports anything besides the authorization code flow; you get redirected to Google login, back to your server, and it sets an oauth2_proxy specific cookie to keep you logged back in to your own server.
Related
I have an on-premise client-server application, which uses Google API. Until now we were happy with out-of-band flow (redirect_uri=urn:ietf:wg:oauth:2.0:oob), with manual copy-paste of authentication code, but Google is going to block it soon.
The problem is that Google requires a fixed list of allowed redirect URIs, but I do not know internal addresses of application server inside the intranets. For desktop client I just use http://localhost/xxx, but I do not know what to do with web clients.
The only solution I see is to set up a public authentication server. The client will pre-register the state token and the actual redirect uri on the authentication server before calling Google authentication. But I am not sure this is a good idea.
First of all I just want to mention that I haver really bad knowledge of this topic. But my problem is that I have an grafana-instance running in openshift that is using oauth-proxy for authentication.
On my company we are using a Kerberos-solution to automaticly authenticate users accessing company domains. The problem is that we want to manage what groups that have access to the grafana-instance and if possible authenticate in the background without the users having to enter any usernames/passwords.
As I understand the current kerberos solution works like this:
User -> company.com -> SSO-server -> [fetch user from LDAP] -> If Authenticated, Redirect to company.com
Is it somehow possible to do something similar:
User navigates to grafana.company.com
grafana.company.com redirects to sso-server
Magic kerberos authentication occurs
Redirects back to grafana.company.com
someway authenticates the user directly from grafana or oauth-proxy
It is possible; any web-based SSO system that asks you for username/password can instead ask for a Kerberos ticket at the same point. (The latter is done using HTTP-level "Negotiate" authentication, also known as "SPNEGO".) Once the SSO system has established your identity, it'll happily issue the same OIDC or SAML tokens regardless of what kind of authentication was used.
For example, the Keycloak OIDC IdP has built-in support for HTTP Negotiate; search the docs for "SPNEGO". Shibboleth IdP (for SAML) has SPNEGO support as well.
Also, any SSO system that supports getting the 'REMOTE_USER' assertion from the web server (instead of using its own credential prompts) can be used with Kerberos, using e.g. Apache mod_auth_gssapi or Nginx spnego-http-auth modules.
So, I have multiple projects, api, etc... And i'd like to have a central sign-in system. So I turn to SSO and the openId PKCE flow.
Let's say I want to use some cloud solution to save time and money - hypothetically, let's say AWS cognito, for its good integration with aws product.
Now let's say my cloud solution is still pretty much half backed in many regards compared to the competition and to my needs, for example we could imagine the hosted ui of the oauth sso login page cannot be properly customized or even translated, which is a no-go.
Now, we can imagine that we understand oauth PKCE code grant flow, and that we build a small server, or a couple of lambdas, to proxy the oauth implementation so that we can build an alternative front. The server would :
make the inital authorize request with the code_challenge provided by the client application, get a state - or in the case of cognito a csrf token - and return that to our "custom login font".
The "custom login front" could call our server with the csrf, the login and the password, and our server in turn would call the login endpoint of the oauth cloud solution, and check if the response is a redirect to our callback with the code provided - grab that code and return it to the login front for it to finally do the redirect after a nice loader has finished moving.
Would it be bad to do such thing, especially knowing that the login POST request to our oauth cloud solution might have to set a dishonest "HOST" header for the request to pass if we cannot host the login front and server on the same domain as our oauth cloud solution ?
And, finally, am I making sense at all ?
How can I use cURL or Postman to read a web page from behind Azure's AD Application Proxy?
I am trying to better understand how OAuth works in order to create some automation scripts that will need to access a server that we have behind an Application Proxy. Currently I am using a web browser and must sign in to my Microsoft account in order to view a web page hosted by the server. This works fine. Seeing as I am able to accomplish this without difficult using a web browser, it seems like I should also be able to accomplish the same using cURL or Postman.
The app that we have registered is registered as a confidential client (Microsoft's "Web App"). The public client option is disabled. It uses the Implicit Grant type to return an ID Token (The Access Token checkbox is not checked, only the ID Token checkbox). I don't have the ability to create a new client secret nor the ability to enable a public client type.
I have tried several of the different OAuth flows, but they all seem to require a client secret (because we are using the confidential client type), which I do not have access to. How am I able to read the web page through the browser despite not knowing any client secrets? How can I do the same via cURL or Postman?
After being redirected to Microsoft's login page and logging in, Azure saves an access cookie in the browser. You can copy this access cookie and include it as part of a request in Postman. This will allow the request from Postman (or curl or whatever) to get to the service behind the Azure AD Application Proxy.
This is enough for my particular use case, but it does come with the problem of having to teach users how to find and copy the access cookie. It would be nice to find a more user-friendly way of getting the access cookie (or something similar).
I have a Windows Phone application which is reading and writing data from a WCF Data Services service which is hosted in and ASP.NET MVC 3 application.
I can configure both client and server as necessary. I'd like to use OpenID if practical, and once a user is authenticated on the phone they should be able to browse through data which is associated with their OpenID.
How should I configure client and server to make that work?
To use OpenID in your app you should look at using an embedded WebBrowser control which connects to the provider site (or your site which can redirect). When the OpenID provider returns to your site (embedded in the browser control) you'd pass necessary identifiers back to the app.
There's an example of doing this with a twitter app (using OAuth) at http://blog.markarteaga.com/OAuthWithSilverlightForWindowsPhone7.aspx
OpenID is an awkward choice. It sounds like the user already has data associated with their account, which means that the user would have to login to the server at some point in time to set up this data, and then login to the app with the same credentials to access this data. The issue is that of securely verifying that the client app has indeed authenticated the user in question. Assuming that the client app (somehow) has the user's OpenID is not enough because the server can't implicitly trust what the client app tells it.
Off the top of my head, I'd say, what could be done with OpenID is as follows.
First, set up OpenID authentication on the server. Then, when the client app needs to authenticate, it should use the WebBrowser control to point to a server URL that, in turn, lets the user authenticate with their OpenID provider, and points the browser back to the server with the authentication info. At this point, the client app is unaware of the user's authentication status, but the server knows who they are. Now, the server can generate a single-use auth key for the client to use. It can redirect to a special URL with that key in it, at which point the client detects said URL, extracts the key, hides the WebBrowser control, and uses that key to talk to the server. I believe that would be a secure way to do such authentication, but like I said, this is just off the top of my head.