Is there a way to retrieve Auth0 logins to a particular client? I have a common set of users across 2 different clients (2 different applications) and would like to get at the login data separately.
You can use the management API to retrieve the logs by client ID, like so:
curl -H "Authorization: Bearer $TOKEN" https://your-tenant.auth0.com/api/v2/logs?q=client_id%3Aexample-client-id
Here are some doc links on getting started with the Auth0 Management v2 API, including how to get a Bearer token:
Management v2. docs
Management v2. tokens
Related
There are two levels of authentication in my API
Basic auth for the API domain (API hosted website is secured through a basic auth)
Basic auth for the specific API call.
I used the following call and domain level basic auth is working. But API call level basic auth isn't working.
curl https://example.com/test.json
-u "abc:abcd1234" // domain level authentication
-k -H 'Authorization: Basic erwf234werwrefdsf234245wewrwer==' // API call level authentication
-d 'data={}'
I do not believe you can it if both services require the same header for authorization.
Both methods (-u and -H) end up putting the information in the same header field (more detail is provided here: cUrls's option "-u" )
Additionally, here is a discussion about the use of multiple headers with the same name, as well as the option for some headers (but not Authorization) to accept multiple values as a list:
Multiple authentication schemes for HTTP 'Authorization' Header
I am using kong as my api-gateway and using a plugin kong-oidc for authentication using keycloak. Authentication process is smooth and running fine. Now I want to add authorization for the requests made to kong for different microservices. I am planning to modify the kong-oidc plugin. I have created a confidential client, role-based policies and resource based permissions along with some users assigned with different roles in keycloak. I want to authorize a user if he has a permission to access a specific resource. I can do that by following request
http://keycloak-url/auth/realms/$realm/protocol/openid-connect/token \
-H "Authorization: Bearer "$access_token \
--data "grant_type=urn:ietf:params:oauth:grant-type:uma-ticket" \
--data "audience=auth-client" \
--data "permission=af-resource" \
--data "response_mode=decision"
I am concerned with permission=af-resource. during the request I can not know the name of the resource but the requested url. Do I have to request to keycloak again to give me the resource-id for the requested-url and then send the above mentioned request for decision or there is another way? Or somehow i can use the information from token-introspection endpoint.
I'm developing a solution that has: an Authorization Server (AS), a Resource Server and two clients. The two clients are: a web app with Angular 2 and a mobile app with Angular 2 + Ionic 2. I have started to develop the Authorization Server following this sample https://github.com/Baeldung/spring-security-oauth
For both the clients, I have decided to use the "Password Code Grant" because the client are trusted by the AS.
But now I have a problem storing the "client secret code" on the apps. Because the API (.../oauth/token) is secured by Basic Authentication so every time that I ask a token to the AS I need to send something like that:
curl.exe -v -u client_id:client_secret http://localhost:8080/backend/oauth/token -d grant_type=password -d client_id=client_id -d username=admin -d password=admin
So, the questions are:
Where I can store safely the client secret code on the apps?
Is it safe to remove the Basic Authentication from the oauth API?
Have I use another code grant type?
Thank you,
Paolo
Applications running in a browser (Angular) are not able to keep their secrets safe, so I would choose the OAuth2 Implicit flow. The implicit flow requires the use of HTTPS for communication with your Authorization Server, since the tokens are transferred over the network.
You should not remove the authentication from the token endpoint - it would compromise other flow types. For example the authorization grant flow doesn't require the client to be served by HTTPS and the auth code can be visible to anyone, so the token endpoint secret is important there (the Resource Server must ask for the tokens using HTTPS).
Using the implicit flow, you will have to check the validity time of the access token and request a new one before the current one expires. For example using the prompt=none auth request parameter.
I have APIs. Some of them are limited to access from third party applications by OAuth.
I also have a web application. Users can login and see their private information.
The API is called from the web application too. My question is what is the good way to access the API with security measures.
1. Third party applications -> OAuth
2. My own web application -> ???
My web application uses session id for authentication. I guess that transferring the session id with HTTP header may be good way but I don't have a confidence.
For exmaple...
$ curl -X PUT \
-H "X-Sample-Application-Id: "My own web application's ID" \
-H "X-Sample-Session-Token: yeoql2dvn7whpm4tbe61viscv" \
If API receive this request, use session for authentication instead of oauth and identify the user....
Any help will be appreciated.
Thanks,
.. I found similar questions
Questions About Consuming Your Own API with OAuth
Update1
Some say JWT(Json Web Token) is good.
https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
http://blog.mitsuruog.info/2014/08/jwtjson-web-tokenwebapicredential.html
Update2
I may be able to use OAuth's "Resource Owner Password Credentials"
https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/709.html
Or... "Client Credentials grant" looks much better.
I'm going to elaborate a bit on this, because it's a good question, and there is a lot of confusion around it -- so bear with me here.
If the API you are trying to protect is going to exclusively be used by individuals for server-side apps, and not third-party developers, I'd highly, HIGHLY recommend you use HTTP Basic Authentication to secure your API service.
The way this works is super straight forward:
For your user(s), generate API Key pair(s) that consist of an ID and Secret. API keys are synonymous with username/passwords. Just generate random ID / Secret values using a UUID library.
When you authenticate against your API service, supply those API credentials in the HTTP Authorization header to identify yourself. Here's how it looks using curl:
$ curl --user my-api-keyid:my-api-key-secret https://api.myservice.com/blah
What's great about Basic Auth is that:
It's very simple to implement.
It's a well defined standard.
As long as you are making requests over HTTPS, and you don't publicize your API keys, you should be safe.
Now -- if you're building an API service where you want to authenticate users from a variety of environments (not just server side applications), you really need to use the OAuth2 protocol.
This is what it was designed for.
The OAuth2 protocol can authenticate users in a variety of ways -- but as a result, is quite complicated. Adding OAuth to your site can be a challenge, even if you're using popular libraries / etc.
Here's how OAuth works (a quick breakdown):
The Password Grant
The Password flow in OAuth is where you exchange a username/password for an Access Token (usually a JWT). You then use the Access Token in the HTTP Authorization header to identify yourself with your API service.
This is what most people do when building SPAs with Angular / React, as well as mobile apps.
The Client Credentials Grant
The Client Credentials flow is where you exchange an API key (just like basic auth) for an Access Token. You then use the Access Token in the HTTP Authorization header to identify yourself with your API service.
This is what people do when building server side apps with OAuth.
The Implicit Grant
This flow is what you see when you log into some place like Facebook. You click a button, are redirected to some other site to authenticate / accept permissions, and finally you're returned back to the main site with an Acccess Token that you use to identify yourself. This is NOT ideal for API services.
The Authorization Code Grant
This flow is exactly like the implicit flow, except you get back an authorization code that you then EXCHANGE for an Access Token that you use to identify yourself. This is NOT ideal for API services. It's slightly more secure.
If you are planning on going with OAuth because of your use case, I'd highly recommend checking out an authentication provider like Stormpath. They automate a lot of this stuff, and solve a lot of complexities around OAuth.
Otherwise, give Basic Auth a go!
I am developing an app to access its own resources via Rest endpoints.
Users are required to acquire access token via email/password. After completed Authentication server configuration, I had this observation:
With:
curl client:secret#localhost:9999/uaa/oauth/token -d grant_type=password -d username=user -d password=password
I am getting the correct response:
{"access_token":"7541a4f6-e841-41a0-8a54-abf8e0666ed1","token_type":"bearer","refresh_token":"d3fdd7e3-53eb-4e7b-aa45-b524a9e7b316","expires_in":43199,"scope":"openid"}
However With:
curl http://localhost:9999/uaa/oauth/token -d grant_type=password -d username=user -d password=password -d client_id=client -d client_secret=secret
I am getting the following error:
DEBUG 4123 --- [nio-9999-exec-7] o.s.s.w.a.ExceptionTranslationFilter
: Access is denied (user is anonymous); redirecting to authentication
entry point
org.springframework.security.access.AccessDeniedException: Access is
denied at
org.springframework.security.access.vote.AffirmativeBased.decide(AffirmativeBased.java:83)
It looks like the client_id & client_secret are not being recognized when send as parameters. Is this a configuration issue or to do with the version of OAuth2 I am using (spring-security-oauth2, 2.0.5.RELEASE)
A lot of example I come across on the Internet suggest approach one should work with OAuth2.
Thanks :)
There's no method of authenticating the Client against the Authorization Server that is mandatory to implement by spec. Two methods that have been specified that MAY be supported are the HTTP Basic Authentication pattern and the HTTP POST parameter pattern that you've used in your examples. Apparently Spring supports only the first, which seems to be supported by the docs at: http://projects.spring.io/spring-security-oauth/docs/oauth2.html
Yes, lots of examples show the client credentials being passed as form parameters, but it turns out that approach is not recommended, while passing the credentials using "Basic" authentication via the HTTP Authorization header is standard.
Section 2.3.1 of RFC 6749 says
The authorization server MUST support the HTTP Basic
authentication scheme for authenticating clients that were issued a
client password.
And further says
Alternatively, the authorization server MAY support including the
client credentials in the request-body using the following
parameters:
client_id ...
client_secret ...
Including the client credentials in the request-body using the two
parameters is NOT RECOMMENDED and SHOULD be limited to clients unable
to directly utilize the HTTP Basic authentication scheme (or other
password-based HTTP authentication schemes).
In my experience, however, there are some servers that, in violation of the RFC, will not accept HTTP Basic authentication and will only accept form parameters in the body.