I'm trying to use the okta api. I was able to use the api to create an authorization server and access policy with my okta domain.
The problem started when I tried adding a rule to the policy. When I tried adding a rule with my regular okta domain which looks like this: dev-1345678.okta.com, I got a 200 response but no rule was actually added to the policy. I then checked the request through the browser when adding one through the api and noticed that they're using a different okta domain which looks like this: https://dev-1345678-admin.okta.com. Only when I used that domain did I get a 201 request instead of 200, and the rule was actually created.
How do I know when I need to use the domain with the "admin" in the url and when not?
Related
I have created two lambda functions
register
login
and both of them are getting triggered from respective "Http APIs" in the API gateway. I have set up the stage for both of them as prod. Now I want to call them using my custom subdomain e.g prodapi.mydomain.com by setting the path as "v1"
prodapi.mydomain.com/v1/register
prodapi.mydomain.com/v1/login
I am able to achieve it for a single API but when I try to do API mapping for the other one using the same path, it doesn't allow that and says "ApiMapping key already exists for this domain name".
Any suggestion on how to achieve this?
can you share the endpoint url, before adding the subdomain, and after adding the subdomain
And can you explain your endpoints, how it should look like before adding the subdomain and after
I tried to integrate Square Payment gateway in my application, but i'm getting following error enter image description here
I've tested it through postman. It's working fine in postman.
It looks like you're attempting to do the HTTP request from the frontend browser (JavaScript). Square doesn't allow that with one of the most important reasons being that anyone would be able to access your personal access token and thus have access to your account.
With that said, you need to create your HTTP request in a back-end service using something like PHP/Java/Ruby/Node.js, etc.
I have an api project written using laravel which uses passport to generate api tokens. These tokens are used to distinguish who is hitting my routes so that the appropriate data is returned. All of this is working currently.
Both the token generation screens and api routes are contained within the same project. So hitting:
example.com
Brings you to the login screen. Once you log in, you generate a token and then use that token in subsequent requests to the api routes. The token is included when making requests for:
example.com/api/route1
example.com/api/route2/id1
Etc.
Toward the end of the project a requirement has come up to increase the security of the login page. I would like to generate a client certificate that I provide to my users that is necessary for accessing the login page.
How would I do this without affecting how I have the api routes setup? In other words, I am looking to have a workflow for users like this:
import certificate into browser
Now that certificate is installed, user can access login page
login, generate token
use token to make programmtic calls to api routes. These calls should not require the landing page certificate.
Is this possible? Or will adding the client certificate for logins affect the api routes as well?
Thanks for any advice.
You could wrap your routes which require a certificate around a middleware. This middleware should to check if the certificate is installed otherwise redirect them to the pages accordingly.
Checkout the docs
https://laravel.com/docs/5.4/routing#route-group-middleware
and
https://laravel.com/docs/5.4/middleware#assigning-middleware-to-routes
You can also use gates and policies for certain actions: https://laravel.com/docs/5.4/authorization
Lets say a user can update a post, but cant delete it. Those policies are helpfull for it
We are using OIDC and IdentityServer in an enterprise deployment where at the moment we control everything (OP, clients, resources, users).
We have an SPA client that connects to its "own" API and will go through it for everything it requires to do. They are however being served from two different domains. (Let's say the application runs on "my.apps/app" and the API in "my.apis/api").
In our current setup, we use Implicit Flow to have the user authenticated in the SPA and then call the API and verify the token within it. This works very well.
We treat our API as a "resource" even though we don't need to and we don't require the user to give consent.
As mentioned, the SPA needs to go through the API for everything it does and this also includes augmenting user properties upon authentication, so the client doesn't even really let users work with it without going through the API.
Given that scenario, our thinking was that we could even be using Authorization Code flow for our OIDC authentication (treating the API as a backend) and get the security "benefit" of the browser never having access to the tokens.
However, due tue the applications being hosted separately we think this would require us to either:
Initiate the authentication request in the SPA, get the Authorization Code in the fragment but pass it later to the API which will in turn request the tokens and have them live in a cookie or something along those lines.
Initiate the authentication request in the SPA but use redirect_uri to the API domain, thus giving the Authorization Code to it which will request the tokens, have them live in a cookie and then redirect to the SPA again.
Basically we want to know if this is a setup that you think would work, what are the security concerns if any, and if it would be recommended for us to go ahead with this or to keep using Implicit Flow instead (specially from a security standpoint).
Say I have an app with a Sinatra REST API at http://example.com:4567. With my app I have a designer working on the front-end. Rather than set him up with a local back-end I edit his hosts file as follows:
127.0.0.1 local.example.com
and his httpd-vhosts.conf as follows:
ProxyPass /api http://example.com:4567
ProxyPassReverse /api http://example.com:4567
so that API calls are proxied to the remote host. I then create a vhost for local.example.com in apache that maps to his local directory where our front-end repo is. This allows me to give him a remote back-end with a local front-end.
The reason for the subdomain is because we do Facebook authentication which has its restrictive domain policies for auth. We can successfully facebook auth a user and get redirected back to the app, but when attempting to get an access token get a 400 response with the message:
{"error"=>{"message"=>"Missing client_id parameter.", "type"=>"OAuthException", "code"=>101}}
I believe the client_id is correctly set as it's set in the rack:oauth:client object correctly, and the flow is identical and only fails when the domain is different. The only thought I have is that facebook might not like that the user auth's from local.example.com while the access token is requested from example.com, but my understanding is facebook will authenticate on all subdomains. I've also whitelisted local.example.com on my App.
Any insight or advice into how to accomplish this? Thanks in advance.
Turns out it wasn't a domain issue, but rather fb_graph, the open source fb api from nov, uses basic auth by default, you need to set auth to something other than ":basic" when you get the access token in order to solve this error.