On Wed, Feb 4, 2015 at 5:15 AM, Prabath Siriwardena prab...@wso2.com
wrote:
If you say Basic Auth is easy - then there is no difference in using OAuth
too:-)
Basically the resource owner credentials grant type was introduced in
OAuth to migrate clients from Basic/Digest authentication
If you say Basic Auth is easy - then there is no difference in using OAuth
too:-)
Basically the resource owner credentials grant type was introduced in OAuth
to migrate clients from Basic/Digest authentication into OAuth...
By looking at the use case - its clearly something to do with the
The discussion is about how to secure APIs, and OAuth2 is the popular
choice here.
How to do SSO to the web front end is a separate question and OpenID
Connect can be one possibility. Like others have mentioned in this thread
above, there can be other ways to login to the web front end, e.g.
Hi Johann,
As I understand (form Dulanja) we need OpenID Connect [1] to fully
integrate with web front-end. so we can keep the token in fount end (in JS)
and do the call using REST. isn't that the way to go?
[1] http://openid.net/connect/
___
+1 for using OAuth security for the APIs. Can't use guys use the API
everywhere concept in this use-case? So that you can simply have the OAuth
security for APIs.
Best Regards,
Lakshitha Harshan
Software Engineer
Mobile: *+94724423048*
Email: hars...@wso2.com
Blog :
+1 for OAuth and IMO in future we should move all authorization in admin
services to OAuth throughout the Carbon. It will be definitely possible
when we are moving from SOAP to REST with Carbon 5.
On Wed, Jan 28, 2015 at 6:03 PM, Prabath Siriwardena prab...@wso2.com
wrote:
+1 for using OAuth..
On Tue, Jan 27, 2015 at 3:17 PM, Anjana Fernando anj...@wso2.com wrote:
Hi,
I guess our admin services are also accessible via basic auth, isn't it?
.. We just thought, as a convenience method for the end user, they can use
their username/password to access our API if required. So basically,
+1 for using OAuth..
Please also think of the cost of maintaining and provisioning keys between
servers in a clustered setup and the requirement of have an OAuth
authorization server.
Please see the approach suggested here [1] self-issued self-contained
access tokens. This approach reduces all
No. We thought, it might convenient for the end user if we provide basic
auth capabilities. We will integrate OAuth functionalities for our REST
APIs.
Regarding our requirement, We have multiple dashboards that validate the
user through single login page. How can we do the backend API
Hi Gihan,
IMO using basic auth will make it vulnerable for dos attacks and less
secure. So you need to think this thru.
There is a possibility of authenticating already logged in users via the
cookie data. But we will need to write a new cookie based oauth grant type
for this. AFAIK we don't
Hi,
I guess our admin services are also accessible via basic auth, isn't it? ..
We just thought, as a convenience method for the end user, they can use
their username/password to access our API if required. So basically, if
using OAuth, other than using SAML2 bearer token grant type or anything
Hi All,
We are going to use a set of REST API [1] to communicate with the data
layer. Basically, we are securing these REST APIs with basic auth. But we
wanted to communicate with these REST APIs with already logged in user as
well. Reason is we have a plan to use these REST API in our Message
On Tue, Jan 27, 2015 at 12:02 PM, Sumedha Rubasinghe sume...@wso2.com
wrote:
Any particular reason for securing product APIs using Basic Auth?
Products like G-Reg, CDM are using OAuth 2.0 tokens for this instead.
+1
Basically API- Everywhere is the platform level solution for this kind of
Any particular reason for securing product APIs using Basic Auth?
Products like G-Reg, CDM are using OAuth 2.0 tokens for this instead.
On Tue, Jan 27, 2015 at 11:53 AM, Gihan Anuruddha gi...@wso2.com wrote:
Hi All,
We are going to use a set of REST API [1] to communicate with the data
14 matches
Mail list logo
