I am currently running two Kohana 3.2 applications:
Web Server
Rest API Server (handles web authentication and all database models)
We are using password granttype/2-legged oauth2 for authentication. When someone performs a login on the webserver, an API authentication request is sent to the API server, based on the response the Auth::instance is set on the web server. Everything works fine up to this point.
We have an automatic crud controller on the API server, but I want to make this available only to an "admin" account after logging in on the web server. I am trying to find a way to pass authentication from Auth::instance()->logged_in() on the web server back to the API server, so that the crud controller is only available if you had been logged in on the web server.
Any creative advice on how to achieve this? The major challenge is that the API server is running ouath2 and auth (ORM driver), but the web server is running a custom Auth driver based on a successful consumer API login.
Here is the flow:
User visits web server
User logs in
web server sends oath2 authentication request to API server
api server access client database validates request, returns
access_token
web server sets Auth::instance()->logged_in() if access_token is
present
CRUD link is displayed based on admin role
CRUD link is a controller on the API server
[need to validate the user was authenticated here]
CRUD controller is displayed (cross-url link, not HMVC included
controller)
Any help will be greatly appreciated.
Related
I have a Web API written using asp.net core. This API will be used to communicate with several other services registered in AAD, which all could be made using different technologies like an MVC application written in asp.net core or a single page application written in Vue.JS. The latter is causing me issues as the SPA won't be run by an application web server and rather something like nginx or apache and therefor won't be able to use a client secret.
I have added API permissions for my API to my apps.
How would I achieve this? I'm currently sending an access token using the Authorization: Bearer access_token header from the client app to the API, but since the client app and the API aren't the same app in the AAD, it's causing issues.
Here's the flow I'm trying to achieve:
All of the requested apps require you to login to the AAD and when requesting data from the API, they'll send the JWT token, which then should validate the token before returning the requested resource back to the client application.
It seems you misunderstand something . You can register your each client as independent application in Azure AD , and assign access permission for your web api .
The latter is causing me issues as the SPA won't be run by an application web server and rather something like nginx or apache and therefor won't be able to use a client secret.
SPA application use Implicit grant flow , so that it doesn't need the client secret when acquiring token .SPA could be independent app , you should provide client id when making authentication with AAD. After getting access token , you could create http request with Authorization: Bearer access_tokenheader for accessing your web api .
Each client(web/spa/native) will acquire access token for accessing web api . On web api side , you just need to validate the token .Validate the claims(issuer,audience) and signature .
We are currently analyzing the API gateway for our microservices and Kong is one of the possible candidate. We discovered that Kong support several plugins for authentication but the all based on users stored in Kong database itself. We need to delegate this responsibility to our custom auth HTTP service and don't want to add these users in API gateway database.
It's possible to do this with some code around, instead of using the OpenID connect plugin; in effect you need to implement an Authorization Server which talks to Kong via the Admin (8001) port and authorizes the use of an API with externally given User Ids.
In short, it goes as follows (here for the Authorization Code grant):
Instead of asking Kong directly for tokens, hit the Authorization Server with a request to get a token for a specific API (either hard coded or parameterized, depending on what you need), and include the client ID of the application which needs access in the call (you implement the /authorize end point in fact)
The Authorization Server now needs to authenticate with whatever IdP you need, so that you have the authenticated user inside your Authorization Server
Now get the provision code for your API via the Kong Admin API, and hit the /oauth2/authorize end point of your Kong Gateway (port 8443), including the provision key; note that you may need to look up the client secret for the application client id also via the Admin API to make this work
Include client id, client secret, authenticated user id (from your custom IdP) and optinally scope in the POST to /oauth2/authorize; these values will be added to backend calls to your API using the access token the application can now claim using the authorization code
Kong will give you an Authorization Code back, which you pass back to the application via an 302 redirect (you will need to read the OAuth2 spec for this)
The application uses its client and secret, with the authorization code, to get the access token (and refresh token) from Kong's port 8443, URL /oauth2/token.
It sounds more involved than it is in the end. I did this for wicked.haufe.io, which is based on Kong and node.js, and adds an open source developer portal to Kong. There's a lot of code in the following two projects which show what can be done to integrate with any IdP:
https://github.com/apim-haufe-io/wicked.portal-kong-adapter
https://github.com/Haufe-Lexware/wicked.auth-passport
https://github.com/Haufe-Lexware/wicked.auth-saml
We're currently investigating to see whether we can also add a default authorization server to wicked, but right now you'd have to roll/fork your own.
Maybe this helps, Martin
Check out Kong's OpenID Connect plugin getkong.org/plugins/openid-connect-rp - it connects to external identity and auth systems.
I have a web app front end and web api back end both written in ASP .Net Core 1.1 MVC. I am using Auth0 as the authentication server, using the "authorization code grant flow".
So the user logs in - i.e. the user gets directed to Auth0's login screen, which, if the username and password were correct, sends the web app back an authorization code, which the web app then exchanges for an access token, which is then used for all web api calls.
Then, the user clicks on a link which makes the web app call upon a web api action. My question is, how can the web api know which user is making the request? Or maybe at the point the user successfully logs in, the web app should call upon a controller in the web api and tell it which user just logged in? Not sure what the best practice is...
Thank you
I will answer in terms of OAuth 2.0 specification.
Specification determines 4 roles:
Resource owner
Resource server
Client
Authorization Server
In your context:
Resource owner is end-user.
Resource server is your Web API.
Client is your web application.
Authorization Server is Auth0.
Follow steps:
Your Web API should be registered on Authorization Server
(https://auth0.com/docs/apis).
Your Web API should be responsible to validate access tokens that
are used for requesting API. This access tokens contains info about
end-user/client (https://auth0.com/docs/api-auth/tutorials/verify-access-token).
You should include Web API scope in authorization request.
You should get access token in your web application and include it in HTTP request to Web API.
I am in the midst of planning a saas app and have been stuck trying to figure out how I want to handle my session management. Here's the scenario:
Server 1: REST API, Rails 4 w/ rails-api gem
Server 2: Front-end, Rails 4, BackboneJS/MarionetteJS
These servers, eventually, will be part of a cluster of similar servers.
The applications are separate because there will also be a mobile app using the REST API and we plan on having 3rd party applications tie into our database via the API.
I've boiled it down to 2 scenarios:
1) Use access_tokens only for authentication on the front-end:
User logs in and sends over email and password over https
They are authenticated via the api and it returns an access_token
All future requests made on the front-end use this access token
2) User database sessions on the front-end and then access_tokens for api calls
User logs in and is authenticated via devise on the frontend server (storing session info in the DB)
An access_token is generated for them and added to the Backbone app initialization for future api requests
I favor #2 simply because every time the user changes the page, I can easily see if they are still authenticated and if not, boot them back to the login page.
But #1 keeps things easy in the sense that the frontend server deals with just that: the frontend stuff.
Does any suggest one method over another? Why?
Does anyone have any other alternatives?
Thanks all!
You're reinventing the wheel by doing using an access_token. Devise already generates a cookie and sends it back when signing in. Just parse this cookie out when the client logs in:
User logs in with backbone app (post request is sent to API server)
Devise does it's thing and authenticates the user, generates the session_id and sends it back in an HTTP Set-cookie header.
backbone app parses the cookie out and caches the session_id value (think of this as your access_token)
each subsequent api call sends the cookie value in an HTTP Cookies header as session_id=cookie-value-here
Note your session cookie name is custom to your app and can be configured in an initializer via:
# /config/initializers/session_store.rb
YourRailsApp:Application.config.session_store :cookie_store, :key => '_your_rails_app_session'
I have several web services that I want to make available to clients. My clients are split into two groups:
users using a web browser (I serve a web page that uses javascript + AJAX to request data from the web services)
applications (e.g. server app pulling data into a client's system)
1) I can solve the former by exposing my web services to external users using the application server and I can use the identity server to authenticate access (haven't worked how to do this out yet).
2) The latter is nicely satisfied by using the API manager. I can happily tell clients to log in to the API manager and subscribe to APIs. The APIs I create are proxies for the web services mentioned in 1).
I know that an API I create in the API manager can include a username and password for accessing the proxied web service. Is it possible to let an API proxy a web service that is authenticated using the identity manager? Sorry I'm reading documentation and struggling to understand if I can do this. Thanks
". Is it possible to let an API proxy a web service that is
authenticated using the identity manager? "
Currently APIManager supports the service endpoints which are secured using basicauth/usernametoken.
If you use identityserver to secure you service, using any other mechanism, that wont be supported by APIManager.
Stodge,
Default API manager authentication mechanism is Oauth. it uses Oauth token mechanism to authenticate all APIs.
Please refer [1],
Here the authentication component also sits in the AM. This can be delegated to a different AM instance if required.
Hope this helps.
[1] http://docs.wso2.org/wiki/display/AM140/Token+APIs