I want to create an OAuth 2 Server mainly for self education purposes. I do understand the concepts the OAuth framework is based on and I do understand the the authentication process(what is send/received and why).
I'm pretty familiar with java and the Spring framework as such my intentions are to use this technologies.
My question is, In order to implement an OAuth 2 Server:
Do I just follow the rfc6749 to the letter and write my code based on this? Handling everything by my self? from the data and how its stored in the database(if a database is used) to serving the same error/message response?
Do I use a dependency or a library maybe, which will prevent me from reinventing the wheel (as far as OAuth 2 is concerned)?
Or is there and already free service which I can install and does exactly with some minor configurations.
Thanks in regards. :)
If you're writing something new from scratch, I would recommend you would take a look at the upcoming OAuth 2.1 spec. Largely compatible with OAuth2, but there's a few features removed and some stuff added. It might be worth starting off with something that's immediately the bleeding edge.
Yes, probably. Unless you can't find a good one?
Yes, there's open source implementations and free hosted services.
I think what you want is Keycloak.
Thanks.
Related
Is it even possible more or less natively consume WCF service from Go application?
I can imagine it should be possible to execute SOAP calls in Go, but WCF is a bit more than that only, for example authorization will probably be a problem also...
Have anyone at least approached this area, or maybe someone can give useful me advice in this "wheel reinvention task"?
Thank you in advance for all your input, ideas and suggestions.
I think you should expose a RESTful Service. I myself have the problem with exposing a WCF Service too many clients using PHP, Go, Ruby and all kind of languages. We never ever got it right, to automatically generate a proxy.
The maybe simplest way is to use WCF, like described in this example:
https://www.codeproject.com/Articles/105273/Create-RESTful-WCF-Service-API-Step-
By-Step-Guide
But I recommend to switch to ASP.NET Core (Migration is not that hard) or if you have the budget I would consider https://servicestack.net/
It may be well beyond the wait time for this. However, here is something really interesting that could help. The situation the authors found themselves is relevant even today in some organizations.
https://github.com/khoad/msbingo
Here's the motivation provided by the authors:
Application/soap+msbin1 encoding was a blocking issue for modernizing services from WCF to platform-agnostic technologies such as Go. We needed to be able to make calls to dependency services that spoke msbin1 and were not going to be updated or even reconfigured, but we did not want to introduce unnecessary complexity such as workarounds like .NET-based WCF request translator proxies or deploying Mono with our service instances. Initially we tried the Mono deployment route, which, while it would have worked well enough, significantly complicated our deployment pipeline, thus erasing one of the major advantages of golang.
I found it a useful starting point to begin experimentation.
I have recently been thinking about how to get my webframework/application-stack right. I'm slowly moving over to scala and functional programming (coming from Python with CherryPy). So it was natural to look into Play as it is the most widely supported framework (now that even Typesafe adopted it). Feel free to correct me if I'm missing something here.
So play is really embracing the idea of stateless webapps and I have a hard time wrapping my head around it in terms of authentication and authorization. Now after some online digging (The definitive guide to form-based website authentication) I came to conclusion that authentication and authorizing must be done on each and every call to my backend (JSON-RPC or whatever), getting away from the old session-cookie idea.
Now whats the best approach to achieve this with todays technology?
And what about:
I thought about "simple" DigestAuth as it is proven and widespread but then it has this similar feel to the old and rusty basic auth.
Thank you!
You can easely get a work solution. But, not a good one. It seems that the advantage of stateless to stateful is no needs of sharing sessions. Easy to scale up. But, do authentication for each call is costly. Sometimes even add some extra database reads ops. This will slow down the response. If you want to cache the authentication result, then there will be no difference with a stateful session solution.
As my opinion. You can not implements a Role Based Access Control in a stateless way!
As for me I use this in my current project https://github.com/t2v/play20-auth, works fine.
i've read this article about authentication library. some of this answer is not satisfy me. my qeustion is:
i know some of the libraries above has not been maintenance
anymore/compatible with Codeigniter 2.0 . but which one who still be
maintenanced ? some of them doesnt have any documentation (tank_auth) would u like to show me the complete documentation instead of basic information founded in the konyukhov's site ?
I plan to make a -dooid-like web or a-identy-like web for
my local colleges.
what is the most suitable authentication for my case?.
i mean it is simple, clear and complete user_guide ,compatible with
codeigniter 2.0 but strong.
excuse me with my english. i am indonesian and i cant speak english well.
I've had great luck and would highly recommend Tank Auth.
It requires only a bit of setup and provides several built in functions for checking if a person is logged in and other useful authentication functions. It's fairly well documented and there's a good community of developers to help if you get stuck.
I am currently developing a very simple web service and thought I could write an API for that so when I decide to expand it on new platforms I would only have to code the parser application. That said, the API isn't meant for other developers but me, but I won't restrict access to it so anyone can build on that.
Then I thought I could even run the website itself through this API for various reasons like lower bandwidth consumption (HTML generated in browser) and client-side caching. Being AJAX heavy seemed like an even bigger reason to.
The layout looks like this:
Server (database, programming logic)
|
API (handles user reads/writes)
|
Client application (the website, browser extensions, desktop app, mobile apps)
|
Client cache (further reduces server reads)
After the introduction here are my questions:
Is this good use of API
Is it a good idea to run the whole website through the API
What choices for safe authentication do I have, using the API (and for some reason I prefer not to use HTTPS)
EDIT
Additional questions:
Any alternative approaches I haven't considered
What are some potential issues I haven't accounted for that may arise using this approach
First things first.
Asking if a design (or in fact anything) is "good" depends on how you define "goodness". Typical criteria are performance, maintainability, scalability, testability, reusability etc. It would help if you could add some of that context.
Having said that...
Is this good use of API
It's usually a good idea to separate out your business logic from your presentation logic and your data persistence logic. Your design does that, and therefore I'd be happy to call it "good". You might look at a formal design pattern to do this - Model View Controller is probably the current default, esp. for web applications.
Is it a good idea to run the whole website through the API
Well, that depends on the application. It's totally possible to write an application entirely in Javascript/Ajax, but there are browser compatibility issues (esp. for older browsers), and you have to build support for things users commonly expect from web applications, like deep links and search engine friendliness. If you have a well-factored API, you can do some of the page generation on the server, if that makes it easier.
What choices for safe authentication do I have, using the API (and for some reason I prefer not to use HTTPS)
Tricky one - with this kind of app, you have to distinguish between authenticating the user, and authenticating the application. For the former, OpenID or OAuth are probably the dominant solutions; for the latter, have a look at how Google requires you to sign up to use their Maps API.
In most web applications, HTTPS is not used for authentication (proving the current user is who they say they are), but for encryption. The two are related, but by no means equivalent...
Any alternative approaches I haven't considered
Maybe this fits more under question 5 - but in my experience, API design is a rather esoteric skill - it's hard for an API designer to be able to predict exactly what the client of the API is going to need. I would seriously consider writing the application without an API for your first client platform, and factor out the API later - that way, you build only what you need in the first release.
What are some potential issues I haven't accounted for that may arise using this approach
Versioning is a big deal with APIs - once you've created an interface, you can almost never change it, especially with multiple clients that you don't control. I'd build versioning in as a first class concept - with RESTful APIs, you can do this as part of the URL.
Is this good use of API
Depends on what you will do with that application.
Is it a good idea to run the whole website through the API
no, so your site will be accessible only through your application. this way This implementation prevents compatibility with other browsers
What choices for safe authentication do I have, using the API (and for some reason I prefer not to use HTTPS)
You can use omniauth
Any alternative approaches I haven't considered
create both frontends, one in your application and other in common browsers
What are some potential issues I haven't accounted for that may arise using this approach
I don't now your idea, but I can't see major danger.
I would like to start using the WCF Rest Starter Kit's HttpClient to build clients for my Restful WCF services and I was wondering...
If anyone is currently experience
any problems with it
Can I be confident that future versions of
the component (just the HttpClient,
not worried about the rest of the
kit) will not contain significant changes to the API?
It seems like a pretty straight-forward component so I can't imagine any major changes with it, but maybe somebody here who is more "in the know" could give me a heads up.
Thanks in advance.
I work on the WCF team and I wrote most of the HttpClient code.
No major known issues. The public issue tracker is at http://aspnet.codeplex.com/WorkItem/List.aspx (search for HttpClient or WCF REST).
Microsoft does reserve the right to change it. That being said, I don't think there will be significant changes to the API that has shipped. (Maybe some minor renaming.) We're mostly considering adding features/capabilities, which shouldn't break your existing code.
A great way to tell us about your usage is via the forum: http://go.microsoft.com/?linkid=9632199 .
Until it's released, Microsoft will surely reserve the right to change it.
On the other hand, if you make sure they know you're using it, you're somewhat less likely to be, ummmm, inconvenienced by any changes.