I am working on an angular application that uses keycloak-angular package for authentication. I want to add a feature which would allow a public user to access the protected resources and for that I have thought to create a default user and use a specific url to log in with that default user and access the protected resources, but I am not able to find a way to supply login credentials and login manually rather than redirecting to the auth/realm page and ask user to login. How do I do that?
If you configure your client to use direct grant you'll be able to get an access token with a simple POST request.
Form an Oauth perspective this is the Resource Owner Password Credentials flow.
Direct grant come with several drawbacks and you might want to
Deploy two instances of your front-end application with separate clients in order to avoid leaking your "more secured" client credentials.
Implement role scope mappings limitations for the "direct grant" public client.
Another easier solution would be to make public resources... public. Assuming you are using some REST API you don't have to protect all endpoints with Keycloak.
Example: with Keycloak Spring Security adapter that'd be something like .antMatchers("/public/*").permitAll()
Related
This is what I am trying to accomplish: I have a static website hosted with Firebase Hosting and it has a Google Forms Form. Upon clicking the submit button, I want to also send the user an email confirming that we received the form. I have written a Firebase function using an HTTP endpoint. However, that endpoint is exposed to the public. Is there any way I can protect this function? I know that we can do an auth verification with a logged-in user but I don't need the visitor to create an account to submit the form.
Thank you!
HTTP triggers deployed by the Firebase CLI are always accessible to anyone with an internet connection. The only access control is provided by Google Cloud to restrict access by IAM, which is not going to be helpful to you here.
What you should do instead is protect the endpoint to be accessible only by users signed in with Firebase Authentication. There are plenty of examples of this.
How to protect firebase Cloud Function HTTP endpoint to allow only Firebase authenticated users?
Callable functions also make it easy to check if the end user is authenticated at the time of the call.
Another possibility might be, to use req.headers["x-forwarded-for"] in order to compare the request's source IP address. It's not exactly a domain-check, because TCP/IP does not know about the DNS, but it still could be combined with a reverse lookup (or simply a list of IP address/es). It depends on the scenario (what the function actually does), because this would also work while not being authenticated. It is from where vs. who ...be aware the another Firebase hosting on the same IP address could not be told apart, but it would rule out direct access from the client-side .
What I'm trying to do is a Silent Authentication with Auth0 as Identity Provider using SAML 2.0 protocol. I don't want to use the Auth0 SDK because the purpose of the Server Provider is to be able to change between Identity Providers. I have read this post and this other.
I updated my login url from
https://{your_domain}.auth0.com/samlp/{client_id}
to
https://{your_domain}.auth0.com/samlp/{client_id}={connection your_db_connection_name}
As mentioned in the first link, but this only allow me to avoid redirections if the user has already an existing session. The second link refers to a parameter in the url:
prompt = none
But this is for OpenId Connect protocol, so I doesn't help me.
The current flow is the following:
User send credentials to my Server Provider (this is useless because
Auth0 requires the credentials in his widget)
The Server Provider requests for SAML authentication to Auth0
Auth0 redirects the user to his login Widget (the user enters the
credentials again)
The user get access
What I want to achieve is:
User send credentials to my Server Provider
The Server Provider Integrates the credentials (here is where I do
not know how) in the SAML 2.0 request
Auth0 receive and authenticate the credentials (without any kind of
redirection)
The user get access
What I'm using:
As Server Provider, Node JS with Express and saml2-js library
As Identity Provider, a Regular Web Application with the SAML2 Web App add-on on Auth0
I am new using SAML and Auth0 and I do not know much yet. Any guide or advice is welcome. Thank you.
(If I have flaws in my English, do not hesitate to comment, thanks)
I have researched about this and discovered that it is not possible to achieve it (not now, perhaps in the future).
The use of HTTP-Post Binding allows to avoid redirection only if a user session already exists. If not, the user will be redirected to the IdP login page (in this case, the login page of Auth0)
There is a profile in the SAML protocol and it is called Enhanced Client or Proxy (ECP), but it is rarely used and recommended for applications that can't use the browser.
Also, only some IdPs support it, like Keycloak and Shibboleth.
I'm trying to create a Javascript application that has a filterable listing of certain kinds of public Facebook events. The thing is, the FB Graph API requires that you provide a User Access token in order to use the search for public events. I really don't want to make people log in to facebook in order to use the website, especially because ANY facebook user's credentials are sufficient to query the events I want to query (ie the search is independent of any user credentials, I just need them because the fb api requires me to have a user access token.)
Do y'all have any suggestions for a work around? I'm thinking about providing my own credentials securely, and just using them to make the actual queries. The thing is I would potentially need to be doing A LOT of queries per minute, so this might not be terribly realistic. Any suggestions would be helpful.
Simply do this server-side not client-side.
You just need an app token (no user token) to do this search, but using this client-side is a bad idea since it would expose your app token publicly.
I'm currently building a frontend client for my own Apigility API.
The API uses OAuth 2.0 Authentication which is working fine.
I want to create an AngularJS Landingpage to let the users authenticate by entering their credentials. Because the Client is created with JavaScript,
I shouldn't save the client_secret in the Client, correct?
I have read a lot of posts, but still haven't the right solution.
Is it correct to use the implicit grant type for this scenario?
This procedure is working, I'm being redirected to the authentication server,
after the client authorization and entering credentials, I get back to the client (authenticated).
But I don't want to get redirected to another authentication page.
Is it also possible to authenticate directly and secure on the angularJS frontend?
Thanks,
Simon
You should take a look at this post i made:
https://stackoverflow.com/a/42443878/2963703
It details how to do this using the Spotify API. Your page won't get redirected, instead a popup window will open in which the user authorizes themselves. Once they're authorized the window will close itself and in your main page you will have the access token you need.
I'm running a webview from a cordova app and want to authenticate a user, I know they have the OAuth strategies but I need to use the email/password combination.
I'd like to keep things simple but may end up having to generate a token.
Open an InAppBrowser that loads an auth flow for firebase
Listen for that auth flow to be completed using this method: http://blogs.telerik.com/appbuilder/posts/13-12-23/cross-window-communication-with-cordova%27s-inappbrowser
Grab the result from the webview again and insert it into the webview firebase instance
I'm guessing that's not possible due to security.
My app is using Amazon login (required) so my alternative would be:
webview loads InAppBrowser with our external url
that loads Amazon auth, then generates a token for Firebase
webview listens for token and grabs it, stores it in localstorage
Edit:
In the firebase docs on logging in with a username/password, I see it returns a token for the session and more information in the authData object:
https://www.firebase.com/docs/web/guide/user-auth.html
Could I then take all the information from that object and send it back over to the cordova webview and then populate that Firebase ref with the information?
Some answers from the wonderfully helpful support at Firebase:
First:
You’re correct – anyone can make a request to sign up, and we don’t expose any capability to secure the url which people can sign up from for email / password authentication.
The main reason that we require / enable origin whitelisting for OAuth authentication, but not for email / password authentication, tends to revolve around sessioning.
The Firebase login server does not maintain sessions (via cookies or any other method), and so requests to the login server for password auth. requires a user credential (the password) for every request. CSRF is typically a risk when a malicious party can take advantage of a user’s session browser, i.e. make requests on behalf of the user to some page where cookies are automatically sent by the browser.
Furthermore, we don’t have a great way to actually do ideal origin-based whitelisting for these pure HTTP requests. We could use CORS, but would have to fall back to JSONP for older browser environments that don’t support it. To complicate matters further, PhoneGap / Cordova apps don’t have the same notion of an “origin” at all, and from the perspective of a server – the calls are indistinguishable from any malicious party making an HTTP request with the same headers.
The OAuth providers, however, use cookies for sessioning and do not require user invention for each auth. request. If you’ve approved a particular Facebook app, you won’t be shown any UI/UX or be prompted the next time that app requests your data – it will be invisible. When we do OAuth, we never have to send any user credentials to Facebook / Twitter / etc., because those are stored in browser cookies for facebook.com / twitter.com / etc. What we need to protect is a malicious party pretending to be a popular, valid Facebook app. and taking advantage of that short-circuit behavior that would get access to user data without the user’s knowledge.
My response:
So, how is that secured? If anyone can make a request to sign up from a
cordova webview (which comes from no specific url, just the app iteself)
then I can't secure from which url people can sign up from? So any site
could use our url "xxx.com" in their config and start registering
users?
That doesn't seem right to me.
I think I still need to have an external url that is whitelisted by you
guys. That would have the login form and do the auth.
But then my question is, can I transfer that auth back to my cordova app?
Is it somewhere in localStorage I can check? I'll have to run some tests.
And final response:
Sure thing – we’re happy to help. I wrote much of the original client authentication code, and can speak to the design decisions and rationale that went into it. Be sure to let me know if you have further questions there.
While we don’t store user passwords in cookies, of course, we maintain a Firebase auth. token in LocalStorage. Our authentication tokens are signed by your unique Firebase secret (so they cannot be spoofed), and can contain any arbitrary user data that would be useful in your security rules.
By default, and when using the delegated login (email + password) service, these tokens will only contain a user id to uniquely identify your users for use in your security rules. For example, you could restrict all writes or reads to a given path (e.g. write to /users/$uid/name) by the user id present in the token (“.write” = “$uid = auth.uid”). Much more information on that topic available on our website.
Your plan to spin up a server to authenticate users with Amazon and generate tokens sounds correct. This is a common pattern for our users who wish to use authentication methods that we don’t support out-of-the-box (ie Amazon OAuth) or have custom auth requirements. Note: once you’ve created those tokens and sent them down to the client, they’ll be automatically persisted for you once you call ref.authWithCustomToken(…). Subsequent restarts of the app will use the same token, as long as it has not yet expired.
This is a topic of interest to me too as I have implemented something similar , twitter digits (native android) + firebase custom login in webview.
I think, as recommended by firebase, you can use other authentication providers and then the firebase custom login.
Do you use the Amazon login in android native code ? If so after login, then generate a JWT token for firebase and use it to access firebase.
If all code is in Html/js app, then maybe you can use custom login and generate a token on your server after making sure its logged in to the Amazon.
The trouble with Android hybrid apps is the following: the JWT token (for firebase) should be created on secure system (eg. server side) not with android java code, other option for hybrid app is to do a http request to generate the token, but I find that less secure, anyone would be able to get a token by finding the URL, than I resort to generate token within android app code, you can change security key/seed for token when doing new releases.
In summary, I don't think firebase studied the problem of mobile hybrid apps.