About serialization, that was my general idea too.
When talking security, I might be biased since my use case is a mix of characteristics both in the "MAY NEED" and "MAY NOT NEED" OAuth, and that's probably the reason I haven't settled yet for a single security framework.
In short, I have 3 types of WWW distributed entities:
a) remote client applications e.g. (smartphone app); b) a Gateway black box that implements RSA, SSL sockets, and is very static (inserted in a home appliance which relays its industry-specific protocol to the WWW, using a third party electronic component. This is made by my potential client). Basically a provider that can be read and written to, but that is vulnerable to eavesdrop and MITM when publishing ServerSockets. It's also very "critical" (think medical application or home climate); c:) a central server which manages authentication and keeps mobile clients aware of the gateway's dynamic location (non-static IP from the consumer's internet connection), incoming listening port AND respective socket _public key_. It also hosts a "register/manage applian
ces" web
app with user authentication
Paraphrasing questions from the referenced article:
Hypothesis - "Do you want a central authentication server that manages authentication and authorization for all your web apps?" A - Yeap, I will need a website that pretty much uses the same credentials as the services I will deploy for _a)_ (+for OAuth)
Hypothesis - "Do you want the allow users to grant temporary permission for third parties to access services on behalf of them?" Although they are indeed temporary, nope since the "services" on the _b)_ endpoint are very low level and do not provide standardized WEB services per say, instead relying on. plain old SSL socket to transport application level messages (- against OAuth)
Hypothesis - "Does your app already manage user logins and authorization?" A - Not yet but eventually it must, and I'm considering Apache Shiro at the moment (- against OAuth)
So from my understanding, OAuth/OAuth2 is indeed overkill since I am already in need to provide an authentication for other components (the web app). Maybe I can just intercept the REST requests just like a login page would, and prepare my mobile clients to answear the challenges for refreshing their security tokens, or something like that
Unfortunately in the case of serialization and deserialization of object graphs to various formats, there is no standardized annotation available (yes, this can result in ...
Settings
TBorba
Hi and thank you for your comment.
About serialization, that was my general idea too.
When talking security, I might be biased since my use case is a mix of characteristics both in the "MAY NEED" and "MAY NOT NEED" OAuth, and that's probably the reason I haven't settled yet for a single security framework.
In short, I have 3 types of WWW distributed entities:
a) remote client applications e.g. (smartphone app);
b) a Gateway black box that implements RSA, SSL sockets, and is very static (inserted in a home appliance which relays its industry-specific protocol to the WWW, using a third party electronic component. This is made by my potential client). Basically a provider that can be read and written to, but that is vulnerable to eavesdrop and MITM when publishing ServerSockets. It's also very "critical" (think medical application or home climate);
c:) a central server which manages authentication and keeps mobile clients aware of the gateway's dynamic location (non-static IP from the consumer's internet connection), incoming listening port AND respective socket _public key_. It also hosts a "register/manage applian ces" web app with user authentication
Paraphrasing questions from the referenced article:
Hypothesis - "Do you want a central authentication server that manages authentication and authorization for all your web apps?"
A - Yeap, I will need a website that pretty much uses the same credentials as the services I will deploy for _a)_ (+for OAuth)
Hypothesis - "Do you want the allow users to grant temporary permission for third parties to access services on behalf of them?"
Although they are indeed temporary, nope since the "services" on the _b)_ endpoint are very low level and do not provide standardized WEB services per say, instead relying on. plain old SSL socket to transport application level messages (- against OAuth)
Hypothesis - "Does your app already manage user logins and authorization?"
A - Not yet but eventually it must, and I'm considering Apache Shiro at the moment (- against OAuth)
So from my understanding, OAuth/OAuth2 is indeed overkill since I am already in need to provide an authentication for other components (the web app). Maybe I can just intercept the REST requests just like a login page would, and prepare my mobile clients to answear the challenges for refreshing their security tokens, or something like that
6:40 a.m., Wednesday June 5
Moderate this comment by email
Email address: tborba@outsoft.pt | IP address: 84.91.197.21
Reply to this email with “Delete”, “Approve”, or “Spam”, or moderate from the Disqus moderation panel.