fujieid / jap Goto Github PK

🏆Gitee's most valuable open source project.🚀💯JAP is an open source authentication middleware, it is highly decoupled from business code and has good modularity and flexiblity. Developers could integrate JAP into web applications effortlessly.

Home Page: https://justauth.plus

License: GNU Lesser General Public License v3.0

Java 99.92% Shell 0.08%

justauth oauth2 oauth2-server sso oidc jap oauth ldap saml basic

jap's Introduction

Just auth into any app

开源地址： Gitee | Github | CodeChina

社区论坛： https://discuss.justauth.plus

API 文档： https://apidoc.gitee.com/fujieid/jap

开发者文档： https://justauth.plus

🎨 JAP 是什么？

JustAuthPlus（以下简称"JAP"）是一款开源的登录认证中间件，基于模块化设计，为所有需要登录认证的 WEB 应用提供一套标准的技术解决方案，开发者可以基于 JAP 适配绝大多数的 WEB 系统（自有系统、联邦协议），就像集成 JustAuth 一样，简单方便。

✨ JAP 有什么特性？

易用性：JAP 的 API 沿袭 JustAuth 的简单性，做到了开箱即用的程度。JAP 高度抽象各种登录场景，提供了多套简单使用的 API，极大程度的降低了开发者的学习成本和使用成本
全面性：JAP 全量适配 JustAuth 支持的第三方平台，实现第三方登录。同时也支持所有基于标准OAuth2.0 协议或者 OIDC 协议或者 SAML 协议的应用、系统，同时 JAP 还提供不同语言版本的项目 SDK，适配多种研发场景
模块化：JAP 基于模块化设计开发，针对每一种登录场景，比如账号密码、OAuth、OIDC等，都单独提供了独有的模块化解决方案
标准化：JAP 和业务完全解耦，将登录认证相关的逻辑抽象出一套标准的技术解决方案，针对每一种业务场景，比如用户登录、验证密码、创建并绑定第三方系统的账号等，都提供了一套标准的策略或者接口，开发者可以基于 JAP，灵活并方便的完成相关业务逻辑的开发和适配
通用性：JAP 不仅可以用到第三方登录、OAuth授权、OIDC认证等业务场景，还能适配开发者现有的业务系统的普通账号密码的登录场景，基本将所有登录相关的业务场景都已经涵盖。针对 WEB 应用，JAP 将提供满足各种不同登录场景的解决方案（和开发语言无关）

🎯 JAP 有什么功能？

💥 适用于哪些场景？

JAP 适用于所有需要登录功能的场景。比如：

标准规范：新项目立项，你们需要研发一套包含登录、认证的系统，并且需要一套标准的、灵活的、功能全面的登录认证功能。
需求灵活：现有登录模块为自研，但是新一轮的技术规划中，你们想将登录认证模块重构，以更加灵活的架构适应后面的新需求，比如：集成 MFA 登录、集成 OAuth 登录、SAML登录等。
力求省事：你们的项目太多（或者是开发语言较多，比如：Java、Python、Node 等），每个项目都需要登录认证模块，想解决这种重复劳动的问题，使研发人员有更多的时间和精力投入到业务开发中，提高研发产能和研发效率。
...

🚀 开源推荐

JustAuth 开箱即用的整合第三方登录的开源组件: https://github.com/justauth/JustAuth
spring-boot-demo 深度学习并实战 spring boot 的项目: https://github.com/xkcoding/spring-boot-demo
mica SpringBoot 微服务高效开发工具集: https://github.com/lets-mica/mica
pig 宇宙最强微服务认证授权脚手架(架构师必备): https://gitee.com/log4j/pig
SpringBlade 完整的线上解决方案（企业开发必备）: https://gitee.com/smallc/SpringBlade

🚀 他们在用

👪 贡献者列表

🏘️ 加入社群

💹 统计图

Gitee

Github

Product Hunt

jap's People

Contributors

Stargazers

Watchers

jap's Issues

`SessionJapUserStore`的`save()`方法参数问题

SessionJapUserStore的save()方法我认为似乎有一些问题。方法体中的这行代码：

JapTokenHelper.saveUserToken(japUser.getUserId(), token);

需要japUser实例的Id作为参数，但有时japUser并没有设置Id属性，比如实现japuserservice接口中模拟的数据就没有模拟其中的Id属性。
没有设置Id更多是开发者的疏忽，但是目前的报错似乎不是很友好。

feat: 希望后续可以支持CAS

Why did you add this feature?

CAS是Central Authentication Service的缩写，**认证服务，一种独立开放指令协议。

1、开源的企业级单点登录解决方案。
2、CAS Server 为需要独立部署的 Web 应用。
3、CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等语言编写的各种web应用。
4、CAS属于Apache 2.0许可证，允许代码修改，再发布（作为开源或商业软件）。

bug: checkAuthenticateConfig方法逻辑

com.fujieid.jap.core.strategy.AbstractJapStrategy类中的方法checkAuthenticateConfig似乎存在一些逻辑问题。

protected void checkAuthenticateConfig(AuthenticateConfig sourceConfig, Class<?> targetConfigClazz) throws JapException {
        if (ObjectUtil.isNull(sourceConfig)) {
            throw new JapException(JapErrorCode.MISS_AUTHENTICATE_CONFIG);
        }
        if (!ClassUtil.isAssignable(sourceConfig.getClass(), targetConfigClazz)) {
            throw new JapException("Unsupported parameter type, please use " + ClassUtil.getClassName(targetConfigClazz, true) + ", a subclass of AuthenticateConfig");
        }
    }

我认为这里的逻辑应该是检查sourceConfig所属的类应该是targetConfigClazz本身或是子类。在我的代码中sourceConfig实参为SimpleProperties，它是SimpleConfig的子类。所以这里调用ClassUtil.isAssignable(...)似乎两个参数的位置写反了，因为我描述的这个情况正好满足ClassUtil.isAssignable(...)方法说明上的第二点：2、目标类型是原类型的父类。

同时我也进行了测试：

当源和目标交换一下位置后才是正确的：

可以支持 JWT 么

或者纯 token 模式，这样就可以用于任何客户端了。

你们的官方文档页面内存暴涨，挂几分钟页面甚至直接OOM

关于SocialStrategy的构造器

SocialStrategy其中两个构造器：

public SocialStrategy(JapUserService japUserService, JapConfig japConfig, JapCache japCache) {
        super(japUserService, japConfig, japCache);
}

public SocialStrategy(JapUserService japUserService, JapConfig japConfig, AuthStateCache authStateCache) {
        this(japUserService, japConfig);
        this.authStateCache = authStateCache;
}

如果调用第一个构造器，可以传入自己的JapCache实现，但此时似乎就只能使用AuthStateCache的默认实现了。同理，调用第二个构造器也是一样。如果我想同时采用JapCache和AuthStateCache的自己的实现，似乎不是那么友好。

能否对此提供支持？或者jap框架这么设计是特意有所考虑，防止出现一些错误。